01
What a specification publishes about itself
Applies to marketplace onlyown storefronthybrid
Alongside the mechanisms it defines, a specification usually states several things about its own maintenance. Four recur across the documents in this field, and each has a factual answer that can be read directly.
| What is published | Where it is usually found | What it establishes |
|---|---|---|
| Who maintains the document | The front matter or a governance page | Which party can revise it |
| What the version identifier signals | A versioning or change-policy section | Whether an unchanged identifier means an unchanged document |
| How a breaking change is announced | The same section | What notice, if any, is published |
| Whether the specification states its own maturity or optionality | The status text of the document | What the maintainers state about its current standing |
These are descriptive facts about the document, not judgments about it. Recording them puts a specification’s maintenance situation next to its feature list, where the two can be read together.
02
What a version identifier is documented to mean
Applies to marketplace onlyown storefronthybrid
A version identifier means whatever its own document says it means, and the meaning is not the same across these specifications.
A UCP version identifier is a date. The specification states that the identifier moves only when a change breaks existing implementations, and that such a change is announced two weeks before it takes effect. Purely additive revisions leave the identifier where it is.2 The consequence is that an unchanged UCP identifier establishes that no breaking change has been published, and does not establish that the document is unchanged.
ACP takes a different approach: it is published as dated snapshots, and the document states its own beta status.1 A snapshot date identifies the exact text that was read, which is what makes a later comparison possible. The stated beta status is a statement the maintainers make about the document’s standing, published in the document itself.
AP2 offers a third case. Its mandate vocabulary was revised, so terms still circulating in commentary refer to the same objects under earlier names.4 Nothing in that vocabulary change is announced by a version number in an implementer’s own code; it becomes visible only on reading the current specification.
| Specification | Form of the identifier | What an unchanged identifier establishes |
|---|---|---|
| UCP2 | A date, moved only by breaking changes | That no breaking change has been published since; additive changes may have been |
| ACP1 | Dated snapshots, with beta status stated in the document | That the reader is looking at the same snapshot; a newer snapshot may exist |
| AP24 | Versioned specification with revised terminology | Nothing about terminology, which changed without an identifier signaling it to implementers |
03
Forms of ownership in the current documents
Applies to marketplace onlyown storefronthybrid
The documents in this field are held in several different ways, and each arrangement is stated publicly.
ACP is maintained by OpenAI and Stripe and published as dated snapshots.1 UCP publishes a technical specification with a stated change policy.3 The x402 Foundation launched operationally under Linux Foundation governance with named founding contributors, which is a matter of public record.6 Each of these describes a governance arrangement; none of them, on its own, describes implementation by any particular business.
The Trusted Agent Protocol adds a statement of a different kind: it says in its own text that merchants are not obliged to use it.5 That is a statement about obligation rather than about maintenance, and it is recorded separately, because it answers a question a governance column does not.
Ownership statements and adoption are separate categories, and they overlap in the sense that the same publication event can carry both — a foundation launch announcement records governance and can also name participants. What it establishes on its own is who holds the document and who is formally involved. Whether a given seller can use the thing described is answered elsewhere, usually in a platform’s own merchant documentation.
04
Where a change is contained
Applies to marketplace onlyown storefronthybrid
Specifications differ in how a mismatch between two systems surfaces, and that difference determines how much of an exchange a change affects.
UCP holds capability negotiation apart from protocol-version compatibility.3 Because the two are separate, a feature that one side does not support is resolved within the negotiation rather than by ending the exchange, while a version mismatch is what prevents the exchange from proceeding at all. The separation is what keeps a single unsupported feature from having the same effect as an incompatible version.
For a merchant, the practical form of this question is which parts of a business a protocol change can reach. Two are distinguished on the record.
- Data that exists independently of any protocol Item records, condition notes, photographs, and identifiers are the seller’s own and remain intact regardless of what a specification does. They are not addressed by any of the documents in this lesson.
- Interfaces that a specification defines How a request is formed, what a response contains, and which capabilities are active are defined by the document and change when it does.
On a hosted storefront, the interface layer is generally implemented by the platform rather than by the seller, which means a published change reaches the platform first. What reaches the seller after that is a matter of the platform’s own communications, and is not something any of these specifications address.
05
What the published notice periods state
Applies to marketplace onlyown storefronthybrid
Where a notice period is published, it describes the release schedule: the interval between announcing a breaking change and that change taking effect. UCP states two weeks.2
A published notice period is separate from whether any particular implementer sees it, because a notice arrives through whatever channel the maintainers publish on. For a seller on a hosted platform, the notice is received by the platform, and the seller’s awareness depends on the platform’s own practice.
The current sources do not describe a formal process by which a merchant can object to, delay, or be exempted from a published change. That reflects what these documents contain; arrangements between specific commercial parties are outside the source set and are not reported here.
06
The governance columns to record
Applies to marketplace onlyown storefronthybrid
The output of this lesson is a set of columns to add to whatever protocol comparison you already keep. Below is that comparison filled in from the current sources, with an unanswered cell left visible.
| Specification | Who maintains it | Version form | Published notice for a breaking change |
|---|---|---|---|
| ACP | OpenAI and Stripe, published as dated snapshots, beta status stated1 | Dated snapshot | Not stated in the current sources |
| UCP | Published with a stated change policy3 | Date-based, moved only by breaking changes2 | Two weeks2 |
| AP2 | Published specification with revised mandate terminology4 | Versioned specification | Not stated in the current sources |
| Trusted Agent Protocol | Published by Visa; merchants stated not to be obliged to use it5 | Versioned specification | Not stated in the current sources |
| x402 | Foundation launched under Linux Foundation governance with named founding contributors6 | Not covered in the current sources | Not stated in the current sources |
Cells reading “not stated in the current sources” describe the source set consulted for this lesson. They mark where a reader would need to consult the document directly rather than inferring an answer from the absence of one.
Two more columns sit alongside these: the date each row was read, since several of these documents are revised at the same address, and the party that would receive a change notice on your behalf, which for a hosted storefront is generally the platform rather than the seller.
07
Summary of the current entries
Applies to marketplace onlyown storefronthybrid
The current documents state the following about themselves. UCP uses date-based identifiers that move only for breaking changes and publishes such changes two weeks ahead.2 It also keeps capability negotiation separate from version compatibility.3 ACP is published as dated snapshots maintained by OpenAI and Stripe, with beta status stated in the document.1 AP2 revised its mandate terminology, so earlier terms remain in circulation in secondary material.4 The Trusted Agent Protocol states that merchants are not obliged to use it.5 The x402 Foundation launched operationally under Linux Foundation governance with named founding contributors.6
The sources do not describe a merchant-facing objection or exemption process for a published change, and they do not state notice periods for every specification listed here. Where a cell in the comparison has no entry, it reflects the documents consulted on the date they were read.
08
Practice
Exercise
Fill in the governance columns
- For each protocol you are tracking, open the document itself and record who maintains it, what form its version identifier takes, and what its status text states.
- Record the published notice period where one exists, and leave the cell explicitly empty where the document does not state one.
- Note which party would receive a change notice on your behalf — for a hosted storefront, the platform — and how that notice would reach you.
- Add the date each row was read, since several of these documents are revised at the same address.
Check yourself
A UCP version identifier has not changed since you last read it. What does that establish?
That no breaking change has been published in the interval. Additive revisions do not move the identifier, so the document may have gained capabilities while the identifier stayed the same.
What does the stated beta status in the ACP document establish?
That the maintainers describe the document as being at that stage. It is a statement published in the document about its own standing, and recording the snapshot date alongside it is what allows a later comparison.
Why does the AP2 terminology revision matter to a reader?
Because commentary written before the revision uses earlier names for the same objects. Nothing in an implementer’s own code signals the change, so it becomes visible only on reading the current specification.
What does the separation of capability negotiation from version compatibility do?
It keeps an unsupported feature from having the same effect as an incompatible version. A feature mismatch is resolved within the negotiation, while a version mismatch prevents the exchange from proceeding.
Does the x402 Foundation launch tell you anything about adoption?
It documents governance and names founding contributors. Whether any particular business has implemented the thing described is a separate question the announcement does not address.
Progress is saved in this browser only. No account, nothing sent anywhere.
09
Common questions
Is a specification held by a foundation more stable than one held by companies?
The documents state their governance arrangements; they do not publish comparative stability records, and the current sources contain no basis for ranking them. What can be recorded is who holds each document and what change process each publishes.
Does a two-week notice period mean two weeks of warning for a seller?
It describes the interval between publication and effect. A notice reaches whoever is watching the channel it is published on, which for a hosted storefront is generally the platform. What reaches the seller after that is the platform’s own practice.
Should a merchant wait for these specifications to stabilize?
The documents state their own version policies and, in one case, their own beta status; they do not state when a stable point is expected. What a record of these columns provides is the current published position, dated, so it can be compared later.
What recourse exists if a protocol changes in a way that breaks an integration?
The current sources do not describe a merchant-facing objection or exemption process. That describes the documents consulted; any arrangement between specific commercial parties is outside this source set.
Does any of this apply to a seller who has not integrated anything?
Directly, no. These documents govern interfaces, and a seller who has implemented none of them holds item records that are unaffected. The columns become relevant when a platform implements one on the seller’s behalf.
10
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- Dated snapshots, a stated beta status, and capability negotiation kept separate from version compatibility are observable properties of a specification that tell an implementer how change will be communicated.
- technical requirement. Supported by Agentic Commerce Protocol repository and specification .
- A maintainer can publish its change policy as a rule rather than a promise: identifiers drawn from dates, additive changes that deliberately leave the identifier alone, and breaking changes carrying a marker plus a fixed notice period of two weeks.
- technical requirement. Supported by Universal Commerce Protocol core concepts documentation .
- Holding capability negotiation apart from version compatibility bounds how far a change travels, because a feature can appear or be withdrawn without the protocol version moving at all.
- technical requirement. Supported by Universal Commerce Protocol official specification .
- A protocol’s central vocabulary can be renamed between its announcement and its current specification while the protocol keeps its name, which makes the age of a secondary description a better guide to its accuracy than the confidence or detail of its writing.
- current external fact. Supported by Agent Payments Protocol specification and documentation .
- A payment network can publish a merchant specification that states in its own text that merchants are not required to use it, which makes participation a commercial decision that a technical reading of the document cannot settle.
- current external fact. Supported by Visa Trusted Agent Protocol merchant specifications .
- Who stewards a protocol, and under what governing body, is exactly the kind of fact a first-party launch announcement can settle, while adoption is not.
- current external fact. Supported by Operational launch of the x402 Foundation .
- Agentic Commerce Protocol repository and specification Agentic Commerce Protocol · Tier A · beta · 2026-04-17 stable snapshot; unreleased development tracked separately
ACP checkout, cart, feed, order, authentication, and extension models. Limit: A beta specification maintained by OpenAI and Stripe does not prove platform adoption, merchant access, conformance, or interoperability.
- Universal Commerce Protocol core concepts documentation Google · Tier A · continuously updated documentation · unversioned documentation published alongside the dated specification
The business profile document and its fields, the capability negotiation algorithm, payment handlers and payment instruments, and signing-key discovery. Limit: Continuously updated documentation carrying no version identifier of its own, so a claim drawn from it is only accurate as at the date it was read; it describes mechanisms rather than establishing that any business publishes a profile or that any platform reads one.
- Universal Commerce Protocol official specification Google · Tier A · published specification · 2026-04-08
UCP discovery, capability negotiation, shopping, fulfillment, and payment-handler models. Limit: The specification states interfaces and normative language; it does not prove that a particular merchant or surface implements them.
- Agent Payments Protocol specification and documentation Google · Tier A · published specification under active revision · live documentation reviewed 2026-08-01
Mandate types and their states, the credential format carrying them, and the human-present and human-not-present transaction flows. Limit: The named mandate types have changed since the protocol was first announced, so secondary coverage of it is frequently out of date; the specification describes an authorization model and establishes nothing about processor acceptance, merchant adoption, or how a contested charge is allocated.
- Visa Trusted Agent Protocol merchant specifications Visa · Tier A · published merchant specification · live specification reviewed 2026-07-30
Recognition and signed-message model for approved agents interacting with merchants. Limit: The specification describes an optional mechanism and Visa implementation details; it does not prove merchant adoption or grant consumer authority.
- Operational launch of the x402 Foundation Linux Foundation · Tier D · official launch announcement · announcement dated 2026-07-14
Linux Foundation governance and stated scope for the x402 Foundation. Limit: Establishes the foundation’s operational launch and stated governance scope, not merchant adoption, production interoperability, settlement finality, or liability allocation.