Domain Working Group (DWG) Charter: Bulk Product Discovery

[jamesandersen]

Problem Statement

There is no standardized bulk mechanism for businesses to publish — and platforms to consume — full product catalogs at scale. Today, platforms rely on bespoke integrations, web crawling, or incomplete catalog data acquired for non-agentic commerce purposes. This creates an N×M integration problem, limits product coverage for agentic commerce experiences, and raises the barrier for new platforms and long-tail sellers alike.

This DWG will define how UCP extends to support bulk discovery feeds — enabling efficient, offline product discovery across businesses using the existing UCP product/variant schema and global identifiers (GIDs).

Supporting artifacts:

• RFC #550: A Bulk Product Discovery Layer for UCP
• Related: UCP 2026-04-08 Catalog Capability (PR #55, #351, #400, #523); Namespace authority binding (PR #530)

Strategic Fit

The UCP TC identified bulk product discovery as requiring a dedicated working group because:

• Cross-company expertise required. Feed infrastructure spans catalog teams, feed-management platforms, and commerce platform providers — each TC member organization has specialized teams beyond their TC representatives that need to participate in design decisions.
• Multiple open design questions. The RFC surfaces five design decisions (wire format, extensibility, sync mechanisms, access/auth, source authority) that benefit from focused, iterative working sessions rather than full-TC agenda time.
• Ecosystem precedent alignment. Existing feed ecosystems (Google Merchant, Meta Commerce, Shopify) have established patterns. Aligning UCP's approach requires domain practitioners from these systems to collaborate directly.
• Natural extension of UCP's funnel progression. UCP capabilities have expanded from checkout → cart → catalog. Bulk discovery is the next logical upstream capability — a low-friction on-ramp that encourages businesses to adopt UCP standards before implementing real-time catalog, cart, or checkout.

Scope

In-Scope

• Feed Transport (Wire Format): How to model feed transport extensibility and negotiated support allowing the ecosystem to leverage preferred wire formats
• Schema / Data Model: The DWG will iterate on the current product data model seeking compatibility with existing feeds and/or interoperability with the ecosystem.
• Feed extensibility: Separation of core product data from platform-specific attributes; inline reverse-domain metadata attributes vs. supplemental feeds joined by GID.
• Contextual feeds: how market-based customizations (e.g. geo based merchandising rules) are materialized in feeds; limits of feed-based delivery vs. real-time lookup and fine-grained merchandising policy resolution.
• Sync mechanisms: Full-snapshot baseline design (single URL vs. chunked manifest); delta/incremental and push notification as staged follow-ons.
• Feed access & authentication: Public vs. authenticated modes; reuse of UCP-Agent/RFC 9421 platform identity for feed access.
• Feed source authority & trust: How feed-URL provenance anchors in the /.well-known/ucp profile per PR feat: define namespace authority binding + broaden RDNS grammar #530's authority-binding model.
• Service and capability specification: Define the discovery service and capability structure, informed by the evolving discussion on services vs. capability-level advertisement in UCP (see PR #589 for context on service scoping, endpoint delegation, and transport binding).
• Capability namespace: Placement of the discovery capability (dev.ucp.shopping.discovery vs. dev.ucp.shopping.catalog.feed or another form).
• PR sequencing: Delivering independently-reviewable, non-breaking PRs aligned with UCP style.

Out-of-Scope

• Business discovery (which businesses exist / seller directory). This is a separate, complementary problem — particularly relevant for participants like marketplaces or certain commerce platforms where underlying merchants may not be easily distinguishable and/or crawling is prohibited. Deferred to a future RFC.
• Collections and Promotions. Bulk feeds for product collections (curated groupings) and promotions (sales, offer codes) are not part of the initial scope. However, the feed architecture is being designed with these extensions in mind, and the DWG's scope may expand to cover them once the base product feed is established.
• Real-time accuracy guarantees. Feeds are point-in-time; stock/availability is verified downstream via cart/checkout.
• Buyer/user-level authentication. Feed access is a platform-level concern, not an end-user concern.

Key Deliverables

• Discovery service and capability specification PR — Define the dev.ucp.shopping.discovery service and capability (as needed per the services model), config.feeds block, canonical UCP-shape product feed with full-snapshot payload (oneOf[feed_url | manifest]), format enum, access model, and provenance rules.
• Program attribute extensibility PR — Reverse-domain metadata extension guidance; supplemental feeds specification (joined by GID).
• Incremental sync & push PR — Delta/incremental feed mode with change-tracking cursors, per-record operations (upsert | delete), and optional push notification transport.
• Eligibility signals PR — Per-product eligibility metadata keys for staged discoverability.
• Product schema additions (if needed) — Additive, non-breaking extensions identified during feed design (e.g., quantity unit/step descriptors, regulatory disclosures), proposed in coordination with the TC.

Deliver By

• The DWG targets late October 2026 to produce PRs for the Key Deliverables noted above
• The expectation is to land these changes in the next major UCP version following the upcoming 2026-08 release
• As the DWG is working in a net new area, it is further anticipated that these changes can be safely backported to the 2026-08 release.

DTC Sponsors

• DTC: Shopping DTC
• Proposed Chairs/Co-Chairs: James Andersen (Meta), Vinod Kumar (Meta), Greg Smith (Google), Alex Jansen (Google)

NOTE: This is a charter nomination for GC approval per the Domain Working Group process

If Interested...

Please complete this form to formally confirm interest.

UPDATE: We'll close down form submissions as of Aug. 21st, 11:59pm PST as we've gathered sufficient interest - thanks!

[igrigorik]

Well-scoped and important area for UCP. Excited for this work to kick into higher gear via this DWG. We've done a lot of thinking and work on UCP-shaped feeds at Shopify already, looking forward to continuing that collaboration within this group — let's go!

[amithanda]

This proposal was discussed & approved by the GC in the meeting on Aug 7th, 2026. Per the DWG nomination process outlined in GOVERNANCE.md, the Chairs/Co-Chairs can proceed to invite nominations and propose the working group members. GC will review and provide final approvals (using the gov:approved tag) once the final composition with DWG members is submitted and reviewed.

[kushalkh04]

This is such a fundamental problem in the commerce/feed infrastructure world and it's great to see UCP taking it on. Excited about the direction here. Would love to bring Feedonomics/Commerce's expertise and ability in making merchants discoverable on UCP-compliant channels to help shape the design through this DWG. Looking forward to the opportunity to participate.

[TomA-R]

Commerce is interested in participating in the Feed Domain Working Group. I'm excited to contribute our experience building commerce platforms and help shape where UCP goes from here.

[Jochem-Timmers]

Thanks for the invite! Channable is excited to join this DWG. The proposal looks very promising and comes at a great time for us. Looking forward to collaborating with everyone and building on our existing UCP collaboration!

[jamesandersen]

@Jochem-Timmers / @TomA-R / @kushalkh04 - With the UCP GC approval for this DWG, we created a sign-up form to formally capture interest. I'm a couple days late on including it here but have just added that (inline above as well). Would you mind completing the form?

[JMathnov]

Hello @jamesandersen, PayPal is very interested in participating in this Feeds Working Group.
I lead product catalog and feed generation for PayPal's agentic commerce integrations, and this working group's scope sits squarely in the problems my team works on day to day. I look forward to hearing others' perspectives on how to solve some of the challenges you've outlined in this issue, and working to standardize this integration so that we all scale the UCP ecosystem!

[westonale]

Hello, Facet would like to contribute on the out-of-scope line: "Business discovery (which businesses exist / seller directory) [...] Deferred to a future RFC."

That deferred problem is the one we have been building against at Facet for the past several months, and the read side of it is running in production. Rather than describe it, here is a way to check it, because a claim you can reproduce in thirty seconds is worth more than one you take on faith.

Reproduce it. Enrollment is self-serve, needs no account, and derives an agent id from a key you generate:

1. POST https://issuer.facet.llc/v1/enroll with {"public_jwk": <your ES256 public JWK>, "proof": <compact ES256 JWS over {"aud":"https://issuer.facet.llc","purpose":"enroll","iat":<now>,"jti":<uuid>}>}. If you omit proof the endpoint replies with the exact claim set to sign.
2. Mint at POST https://issuer.facet.llc/v1/tokens, private_key_jwt client assertion, resource=https://facet.llc/v1 (RFC 8707). The discovery document is at https://issuer.facet.llc/.well-known/openid-configuration.
3. POST https://api.facet.llc/v1/discover with Authorization: Bearer <token> and a body like {"query":"florist","limit":3}.

The credential is a Facet KYA, an ES256 JWT. https://issuer.facet.llc is the default issuer; /.well-known/agents.txt is open without a token and lists which issuers a given host trusts, alongside a Directory: pointer to the endpoint above. A consumer-side reference client is public at github.com/Facet-llc/shopping-skill.

A row comes back looking like this:

{
  "ubi_id": "ubi:us:ca:alameda:94501:blue-dot-cafe-coffee-bar",
  "name": "Blue Dot Cafe & Coffee Bar",
  "naics": 722515,
  "address": "Encinal Avenue, Alameda, ca, 94501, us",
  "taxonomy": ["food-beverage", "view-handoff"],
  "claim_status": "unclaimed",
  "terminal_url": null,
  "handoff": { "phone": "+1...", "directions_url": "https://..." },
  "reputation": { "avg_score": null, "total_interactions": 0 },
  "capabilities": null
}

Filters the endpoint accepts today: free-text query, near {lat,lng} plus radius_km, naics[], taxonomy[], capabilities[], min_reputation, claimed_only, and an edge {connected_to, relation} for graph traversal between businesses. At least one filter is required, deliberately: there is no "give me everything" call.

Five design decisions that shaped what we built, and that I think transfer directly to the RFC.

1. The identifier is the whole problem, and it has to exist before the business does anything. A seller directory is defined by the rows that never opted in, so you cannot key on a merchant-supplied id, an account, or a domain. Ours is derived and human-legible: ubi:<country>:<region>:<locality>:<postcode>:<slug>. Deterministic derivation means two ingests of the same business converge on the same id without a resolution service. The consequence the spec has to settle up front: a derived id encodes the shape of its source record, so the RFC must decide whether ids are stable-and-immutable or mutable-with-aliases. That is not deferrable to implementations, because it changes what a consumer is allowed to cache and for how long.

2. Claimed versus unclaimed belongs in the row, not in a separate namespace. We carry claim_status and terminal_url on the same row, so an owner claiming their business is a state transition on an existing identifier rather than a migration into a different index. An agent that discovered a business while it was unclaimed keeps a stable reference to it after the owner shows up and lights up a commerce endpoint. The alternative, two disjoint namespaces for discovered-versus-claimed, breaks every reference an agent captured before the claim.

3. Non-transactable is a first-class outcome, not an edge case. The most common honest state for a business in a directory is "no commerce endpoint, hand off to a human." Every row carries a handoff with a phone number and a directions link, and one taxonomy value is view-handoff, so a discovering agent always has a next action even when the business cannot be transacted with programmatically. A bulk discovery format whose terminal row state is always machine-purchasable will describe a small and unrepresentative slice of commerce; the non-transactable path has to be expressible in the schema.

4. Classification quality, not transport, is where the cost lands. The charter reasonably spends its scope on wire format, sync, and extensibility, and those are the tractable parts. The hard part across the long tail is that no single classification source is authoritative, and bulk industry codes disagree with each other. If the RFC standardizes a category vocabulary without also standardizing a way to express confidence in a category and to carry a competing classification from a second source, consumers will filter on values no one can vouch for. This is the field we would most want to get right in the spec.

5. The access model is a different axis from the auth model, and #682 already has it half in scope. The charter lists "Feed access & authentication: public vs authenticated modes" and "reuse of UCP-Agent/RFC 9421 platform identity for feed access." Worth separating who is asking from what they are therefore allowed to see. We serve two projections of the same directory. A caller presenting a valid credential gets the full row, including coordinates and unclaimed businesses. The reduced projection, claimed and opted-in rows only with coordinates stripped and a tighter cap, is enforced at the origin independently of the edge, so the full index cannot leak even if the edge gate in front of it is bypassed. Publishing precise coordinates for businesses that never opted into anything is a different act from publishing a merchant's own advertised endpoint, and which one a caller receives should be expressible in the format rather than left to each implementer.

Point 5 is also where business discovery and the in-scope bulk product work stop being cleanly separable. A feed's authority binding anchors in /.well-known/ucp per #530, and a business directory needs the same anchor to answer "is this endpoint really this business." Specified independently, the two will land on different answers to the same question.

The offer. We would like to write the deferred business-discovery RFC, or co-write it with anyone who has been down this road. Not asking to widen this DWG's scope: the bulk product work is upstream of us, and its authority-binding and access decisions should land first so the directory spec adopts them rather than contradicts them. Happy to write it up as a standalone RFC and let it be judged on the text. The reproduction steps above stand on their own, and I would rather people run the system than read a proposal about it.

[jamesandersen]

A hearty thanks to the community for the interest in the Bulk Product Discovery domain working group we've proposed to form. Here's the list of interested candidates for UCP governing council review / approval:

• Kushal Khatri – Feedonomics
• Tom Arbesser-Rastburg – BigCommerce
• Jason Mathnov – PayPal
• Jochem Timmers – Channable
• Sagar Rastogi – Wayfair
• Zhaocheng LI – Shopline
• Yunfat HON – Shopline
• Kelvin PENG – Shoplazza
• XU Chao – Shoplazza
• Sarath Surendranath – Stripe
• Reid Kairalla – Stripe
• Ilya Grigorik – Shopify
• Tejas Mehta – Shopify

[amithanda]

Thanks James/Greg/Vinod and Alex for conducting the due diligence and submitting the DWG member list per the process outlined. You now have formal approval from the GC to start with the official proceedings of this DWG. Please keep all the high level discussion points and design decisions from the DWG publicly posted so that we can continue to gather open community feedback to strengthen the value prop and design. All the very best for your next steps!