View the Roadmap
Live board with RFCs and epics across Creative, Media Buy, Signals, Governance, and more.
Active release cycles
3.2 release-candidate readiness
The final beta and RC preparation are focused on making the compact commercial lifecycle usable, verifiable, and legible—not adding another broad feature wave.
The exact candidate scope remains visible in the
3.2.0 milestone.
3.3 working-group cycle
3.3 will deepen production operation around the lifecycle without forcing breaking changes that belong in 4.0.
Each issue starts in exploration and carries
needs-wg-review. Working groups
will select bounded 3.3 slices from adopter evidence; incompatible identity,
account, or security changes move to the 4.0 accumulation window.
Where contributions are needed now
AdCP is actively seeking implementations and domain expertise—not only schema suggestions—in these areas:
Join the relevant working group, comment on the
linked issue, or bring a runnable implementation and test fixture. Evidence
from production behavior carries more weight than a hypothetical object model.
How the Roadmap Works
The board has four columns representing the lifecycle of a roadmap item:
Each item has two fields:
- Protocol — which area of the protocol it affects (Creative, Media Buy, Signals, Brand Protocol, Governance, SI, TMP, Platform, Website, Addie, Certification)
- Kind — whether it’s an RFC (protocol change needing community input) or an Epic (major deliverable spanning multiple PRs)
What Belongs on the Roadmap
Not every issue or PR belongs here. Roadmap items are protocol-level changes, new capabilities, and strategic initiatives that affect adopters. An issue qualifies if it meets at least two of:- Protocol surface — changes what agents or platforms interact with
- Audience impact — would influence a prospective member’s or builder’s decision
- Multi-issue scope — spans more than one PR
Adding Items to the Roadmap
Any issue labeledrfc or epic is automatically added to the board. To propose a roadmap item:
- Open a GitHub issue describing the proposal
- Add the
rfcorepiclabel (maintainers can also do this during triage) - The issue appears in the Exploring column
- A maintainer sets the Protocol and Kind fields on the board
Triage and working-group review
Maintainers triage new roadmap candidates into the relevant working group. Items carryingneeds-wg-review are explicit agenda candidates: the group must
validate the adopter problem, choose the smallest interoperable slice, identify
an implementation owner, and decide whether the work is additive in 3.3 or
belongs in the 4.0 breaking-change window.
The board is reviewed monthly for stale status, missing owners, and roadmap
items that lack implementation evidence. To lead or contribute to a cycle,
comment on its issue and join the relevant working-group channel on Slack.
Version Milestones
Named milestones group roadmap items that will ship together in a future major version. Each milestone lists accepted RFCs — exploratory items (community input open) remain on the main board until maintainers decide to land them.v4.0 — target early 2027
v4.0 is the next breaking-changes accumulation window, targeted for early 2027 under the release cadence policy. Breaking changes are gathered here so the ecosystem can plan a single migration window rather than chase per-minor deprecations. Items listed below are committed floor requirements for v4.0; additional items will be added here as RFCs are accepted.
This milestone is intentionally not a “security release.” It is the version where accumulated breaking changes across protocol surfaces land together. Request signing is the current floor requirement; other accepted RFCs carrying breaking changes will be added here as they progress through the
rfc label lifecycle on the main board.
Release History
For detailed release notes and version history, see:- Release Notes — per-version feature summaries
- CHANGELOG.md — technical changelog
- GitHub Releases — release archive
- Versioning & Governance — versioning model and release cadence