Skip to main content
Some AdCP surfaces are published in a release but not yet frozen. They are shipped so implementers can begin building against them, but they carry a weaker stability contract than stable surfaces. This page defines that contract. Experimental status is the escape valve that keeps the 3.x stability guarantees credible. A surface is either stable — in which case it cannot break inside 3.x — or explicitly experimental, in which case it can. There is no undeclared middle ground. For a list of the protocol’s non-goals and deferred items, see Known Limitations.

​
What counts as experimental

An AdCP surface is experimental when both of the following are true:
  1. Its schema carries x-status: experimental at the schema root or on the specific property.
  2. A seller implementing it declares the surface in experimental_features on its get_adcp_capabilities response.
Both markers are required. The first tells the ecosystem the surface is not frozen; the second tells a specific buyer that this specific seller has opted in to the experimental contract for this surface. A seller that implements any experimental surface MUST list it in experimental_features. Sellers that do not list an experimental surface MUST NOT implement it — there is no “silently experimental” mode. An experimental feature id covers a cluster of related tasks. A seller that implements any task in the cluster (e.g., get_rights but not acquire_rights or update_rights) MUST still declare the cluster’s feature id (brand.rights_lifecycle). Partial implementation is allowed; silent implementation is not.
x-status: experimental is a schema-local annotation. It is not inherited through $ref — a stable schema that references an experimental sub-schema does not automatically become experimental. The experimental_features declaration on get_adcp_capabilities is the authoritative runtime signal; x-status is an authoring hint for schema readers and tooling.

​
Contract for experimental surfaces

Inside 3.x, experimental surfaces MAY change in ways that stable surfaces cannot:
  • Fields may be renamed, removed, or have their type changed
  • Required fields may become optional and vice versa
  • Enums may have values removed or renamed
  • Task names may be renamed or removed
  • Error codes introduced for an experimental surface may be renamed or removed
Notice requirements for breaking changes to experimental surfaces:
  • At least 6 weeks published in release notes and the changelog before the change lands
  • A migration note describing the change, with before/after examples where possible
  • Where feasible, an alias accepting both old and new forms in the release that introduces the change
This is a deliberate relaxation of the 6-month deprecation notice that applies to stable surfaces.
Why experimental exists. The architecture committee uses this label on surfaces that are genuinely part of the core protocol but not yet field-tested. Without an iteration path, AdCP would either ship rigid schemas nobody has deployed or hold features back until they are perfect. Neither serves implementers.
What does not change for experimental surfaces:
  • Authentication, transport, and core security requirements. These are version-level concerns and never change inside 3.x, experimental or not.
  • Idempotency semantics. A seller’s declared idempotency contract applies to experimental surfaces the same way it applies to stable ones.
  • Error envelope shape. Experimental surfaces return errors using the same envelope as stable surfaces; only the specific codes may shift.

​
Graduation to stable

An experimental surface graduates to stable when ALL of the following are met: Two implementers is a lower bar than one because cross-implementation friction is what shakes out spec ambiguity. A single implementer can match their own schema by reflex; two cannot. When only one implementer is ready, buyer-integration signal substitutes — that signal covers the buyer-side ergonomic bugs that a solo implementer would otherwise miss. Graduation is never automatic. The architecture committee reviews graduation PRs and may require additional cycles if the surface still shows signs of instability.

​
Graduation cadence

The architecture committee reviews experimental surfaces at each 3.x release. Every release’s notes include, for each experimental surface:
  • Current status (still experimental / on track to graduate / under active breaking revision)
  • A list of changes the next release is expected to carry
  • A pointer to the most recent breaking-change notice for the surface, when applicable
Enterprise procurement teams can subscribe to release notes to track experimental surfaces on a predictable review cadence; there is no separate mailing list or ticketing process.

​
Client behavior

Buyers integrating against AdCP sellers SHOULD:
  • Inspect experimental_features before relying on experimental surfaces. A seller that does not list an experimental surface is asserting it does not implement that surface.
  • Pin to specific 3.x releases when depending on experimental surfaces, or subscribe to release notes for the features they consume.
  • Design retry and error handling to tolerate new error codes added to experimental surfaces between releases.
  • Treat experimental surfaces as unsuitable for regulated workflows without additional vendor assurance. Experimental is not a claim of compliance-grade stability.

​
Buyer-side refusal

Buyers that do not want to interact with experimental surfaces — typically for regulated workflows, compliance-sensitive deployments, or procurement policies that forbid non-frozen features — enforce this client-side. The pattern:
  1. At capability discovery, read experimental_features from the seller’s get_adcp_capabilities response.
  2. Filter before invocation. Do not call tasks that belong to experimental feature ids your policy rejects. The list of tasks per feature id is published in the canonical experimental-surfaces list below.
  3. Short-circuit upstream. When an orchestrator or upstream caller requests behavior that would require an experimental surface, return a policy-level error (e.g., the caller’s own POLICY_EXPERIMENTAL_REFUSED) rather than attempting the call. The refusal is the buyer’s concern, not the seller’s — sellers MUST NOT be expected to infer buyer policy.
There is no general wire-level refusal field in 3.0. Buyer-side filtering remains the rule for accepting or refusing experimental behavior. The experimental sync_principal task adds a deliberately narrower reciprocal surface for durable connection resources: callers can declare supported reporting destination paths and webhook registrations, but it does not mirror the seller capability document or carry a generic feature-refusal policy.

​
Current experimental surfaces

Schemas marked with x-status: experimental are the authoritative source. The canonical list of feature ids for experimental_features in AdCP 3.x: Graduation progress and notice of upcoming breaking changes will be called out in the release notes for each 3.x release starting with 3.0 GA.

​
Relationship to extensions

Experimental status is not the same as an extension. Extensions live in the ext.{namespace} field and are governed by the extension registry; they are permanently out-of-band for the core protocol. Experimental surfaces are in the core protocol — they are candidates for promotion to stable, not third-party additions. A surface should be experimental when the architecture committee intends it as part of the core protocol but is not yet willing to freeze it. A surface should be an extension when it is domain-specific, maintained outside the core protocol, or unlikely to apply to the broader AdCP ecosystem.