On 2 September the Universal Commerce Protocol's Bulk Product Discovery Domain Working Group held its kickoff — twice, once for Atlantic time zones and once for Pacific — and on 9 September it met again as a single weekly session. Consolidated minutes for both meetings are now in the public record.

The group was chartered to do one thing: turn RFC #550, a proposal for publishing whole product catalogs as feeds, into specification that the Shopping Tech Council can review and merge. Its charter was approved by the Governing Council on 7 August, and it targets pull requests by late October.

As far as the public record shows, it is also the first Domain Working Group UCP has chartered and seen meet. The payments working groups for tokenization and buy-now-pay-later only opened for statements of interest on 2 September, and a proposed Services group was, as of July, still at the exploratory stage. So this is the first look at how the model actually runs.

#What a working group is — and who is in this one

A working group is not a smaller council. Under UCP governance, three or more organizations submit a charter to the Governing Council, which approves the charter, the chairs and the final membership. Once chartered, the group has autonomy to define capabilities for its domain — but every artifact it produces is reviewed and approved by the Domain Tech Council that sponsors it. Here, that is the Shopping Tech Council.

The approved roster covers eleven organizations:

That mix is the point. The charter argues that feed infrastructure spans catalog teams, feed-management platforms and commerce platforms, and that the existing feed ecosystems — Google Merchant, Meta Commerce, Shopify — have established patterns that practitioners from those systems need to reconcile directly. Feed consumers, feed tools and the platforms that generate feeds are all represented.

#The problem it was chartered to solve

The charter's problem statement is short: there is no standard way for businesses to publish, and platforms to consume, full product catalogs at scale. Platforms rely on bespoke integrations, web crawling, or catalog data gathered for non-agentic purposes. Every new platform has to integrate every source separately.

The kickoff minutes add three sharper versions of that problem.

Ingestion cost. Crawling is described as the common fallback for product discovery, and an expensive, capacity-intensive one. Storefront builders' public APIs do return structured data, but without a standard each source needs its own integration.

Product identity. When feeds pass through intermediaries, the intermediaries often mint their own product IDs. An agent that later tries a live cart call or a price check against the merchant fails, because the merchant does not recognise the ID. The minutes record that current UCP catalog endpoints return null for identifiers created by third-party aggregators, and frame this as an ecosystem problem rather than a protocol failure: authoritative merchant IDs need to survive the trip. Anyone who has debugged variant data will recognise the failure: the agent's identifier and the merchant's stop matching, and the live call is where it surfaces. It is also the survival problem the commercial provenance thread is working on from the other direction — context that has to persist, unaltered, from the moment something is recommended to the moment it is bought.

Context. Price and availability vary by geography, by whether the shopper is logged in, and by campaign. The group noted it is often impossible to materialise every variant of a feed, and that zip-code-level pricing and regional shipping make a basic feed insufficient on its own. UCP already has one contextual primitive nearby: location search and lookup, shipped in the August release.

#What the group has agreed so far

Two meetings in, the positions recorded in the minutes run from firm consensus to explicitly parked.

The group has also agreed how it decides. Because no single session can hold every time zone, decisions are made asynchronously in a position log: a recommendation proceeds if nobody raises a substantive objection, and conflicts go to a deep-dive session. Raw transcripts and recordings will not be published; sanitised minutes will.

One placement question is not the group's alone. Where the feed handshake and manifest endpoint sit in a business profile intersects the Shopping Tech Council's wider discussion of services versus capabilities, and the minutes flag it for council direction. The charter leaves the capability name open for the same reason — dev.ucp.shopping.discovery or something closer to the catalog, such as dev.ucp.shopping.catalog.feed.

#What it is deliberately not doing

The charter rules four things out, and a fifth follows from how the group is set up. Each one matters for anyone planning against it.

• Business discovery — which businesses exist at all — is deferred to a future RFC. The charter notes it matters most for marketplaces and platforms whose underlying merchants are hard to tell apart, or where crawling is prohibited.
• Collections and promotions are out of the first version, though the architecture is meant to allow them later.
• Real-time accuracy guarantees. Feeds are point-in-time; stock and availability are verified downstream, at cart and checkout.
• Buyer-level authentication. Feed access is a platform-level concern, not an end-user one.
• Other verticals. Nothing in the charter or the minutes touches lodging or food. The group is sponsored by the Shopping Tech Council, builds on the existing product and variant schema, and both candidate capability names sit under dev.ucp.shopping. Discovery for rooms and menus has no owner yet: the first lodging capability puts upstream search and discovery out of scope, and the Food charter leaves the menu catalog to its second phase. The retail, lodging and food guides track where each vertical stands.

#The real-time half already exists

The group's first consensus — that a feed never stands alone, and the live APIs stay authoritative — is worth reading against what is already deployed.

Of the roughly 17,200 verified businesses in our census, 17,101 declare catalog search and 17,099 declare catalog lookup — about 99.5% on both. The real-time side a feed would sit in front of is effectively universal among UCP stores today. No verified business declares a feed or discovery capability, because there is not yet one to declare.

That is the useful shape of this work. It is not replacing the catalog APIs; it is adding a cheaper upstream layer for the discovery that happens before an agent ever makes a live call — and the identity problem the kickoff described is the bridge between the two. A feed that carries the merchant's own product IDs lets an agent go from "found it in a feed" to "checked it live" without a translation step in between.

We crawl, so we read the line about crawling being the expensive fallback with some interest. It is a fair description. It is also why the group paired the two halves: a published feed records what a business says it sells, and a live call records what it will actually sell you right now. When we built a test store that listed a product as in stock and refused every attempt to add it to a cart, the agents we ran against it had only the live call to tell them the listing was wrong. Those are different vantages, and the gap between them is where the useful information is.

Parsing is also only the first layer of feed quality. The same study found agents treating text in a product description as if it were store policy. A feed moves exactly those fields into an agent's context, at scale — so a record can parse cleanly and still mislead. That makes the group's open question about diagnostics worth watching closely.

#The risk the group wrote down itself

The most candid line in the minutes is a risk the group recorded against its own work. At the kickoff, one of the Google co-chairs cautioned against creating another siloed standard, noting that no merchants were represented in the room and that feed changes are costly for merchants to implement. A Shopify participant countered that the organizations present collectively represent a very large number of merchants, and that the aim is a coherent ingestion path for agent-based discovery rather than a replacement for existing formats.

The group's resolution was to position UCP as an additional standard, not a mandated convergence, and to track merchant representation and adoption cost as an open risk as scope is refined. That is the right thing to have written down. A feed specification is only as good as the number of businesses that bother to publish one, and the people who have to generate and host those feeds are not yet at the table.

#The calendar

• 7 August — charter approved by the Governing Council
• 25 August — formal approval to begin proceedings posted to the charter
• 2 September — kickoff, in two sessions
• 9 September — first weekly session; architecture direction aligned, first-phase scope proposed
• 11 September — deadline for review comments, to carry into the next Shopping Tech Council meeting
• Late October — target for the working group's pull requests

The charter expects the result to land in the next major UCP version after the 2026-08 release, and anticipates that, as net-new surface, it can be safely backported to 2026-08 as well. The kickoff aligned the timeline with the November/December release cycle. As of 9 September, one of the five deliverables — the discovery service and capability specification — is in progress; the other four have not started.

#What we'll be watching

We don't write the spec. We measure what happens after it ships, from the public record, the same way for every business.

For this group, that means three things. Whether the first-phase scope is settled and taken to the Shopping Tech Council on schedule. Where the capability lands, and under what name, once the services-versus-capabilities question is answered. And, after it ships, whether businesses publish feeds at all — and whether the product IDs in those feeds resolve when an agent calls the live catalog behind them.

The first two will show up on the protocol tracker. The third will show up in the capability data, next to a catalog layer that is already almost everywhere.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• Issue #682 — Domain Working Group Charter: Bulk Product Discovery
• Issue #550 — RFC: A Bulk Product Discovery Layer for UCP
• Bulk Product Discovery DWG minutes, 2026-09-02 (kickoff)
• Bulk Product Discovery DWG minutes, 2026-09-09
• Bulk Product Discovery DWG — chairs, scope and deliverables
• UCP Governing Council minutes, 2026-08-07
• UCP GOVERNANCE.md — Domain Working Groups
• Related coverage: The Payments Tech Council is seated · The v2026-08-25 spec update · UCP variant data guide · Commercial provenance in the cart · What shopping agents do when the store misbehaves · UCP's first lodging capability · Product discovery