No published schema, and no food namespace. The Food Technical Council was seated on 16 July 2026 and the charter (UCP issue #518) sets a three-phase roadmap, but the v2026-08-25 release ships capabilities under dev.ucp.shopping.* and dev.ucp.common.* only — nothing under a food namespace. There is no machine-readable food-ordering spec to validate against yet. We track it and will validate the moment it lands.

The founding members announced on 16 July 2026 are Block (Square), DoorDash, Google, Toast and Uber Eats — the group that will author the food-ordering capabilities.

The checkout core: identity linking (unlocking loyalty status and rates, including new-user setup), a checkout capability covering fulfillment selection, loyalty, tips and age-restricted journeys like alcohol, and a get-order capability for tracking links and confirmation. The menu catalog, conversational cart and discounts come in Phase 2; detailed tracking, voice ordering and payment fingerprinting are Phase 3.

Like the lodging charter, food ordering sequences the money-moving core first: identity, checkout and order confirmation are Phase 1, while menu discovery and cart building are Phase 2. The charter also leans on UCP primitives that already exist — identity linking and loyalty — rather than rebuilding them.

Not decided in public, and not published. As of the v2026-08-25 release the only namespaces in the spec are dev.ucp.shopping.* and dev.ucp.common.* — there is no dev.ucp.food.*. UCP's convention is a reverse-domain name whose authority is the governing body, and dev.ucp.* is reserved exclusively for capabilities governed by the UCP Technical Council responsible for that domain, so food capabilities will sit under dev.ucp.* once the Food TC publishes them. The exact segment is the Food TC's call and we won't guess it here — anything a vendor ships in the meantime belongs under its own domain (for example org.acme.menu), and our checker validates any declared namespace against the spec's authority-binding rule regardless of who defines it.

Yes — but for groceries, and through Shopping rather than the Food Ordering charter. The release ships location search and lookup, deterministic timezone-aware operating hours, fulfillment location context with explicit shipping-versus-pickup destinations, and fractional quantities with sale-basis pricing for goods sold by weight, all as shared dev.ucp.common.* capabilities. Delegated IdP sign-in and a loyalty extension landed too, which map onto the charter's Phase 1 identity work. Nothing restaurant-specific shipped: no menu or modifier schema, no 86'd-item status, no age-restricted checkout, no tips or delivery-fee handling. A grocer can declare UCP location and buy-by-weight capabilities today; a restaurant still cannot express its menu.

Not in the spec. Google frames grocery as part of shopping and local retail fulfillment, and the v2026-08-25 primitives that serve it — location, hours, fractional quantities — shipped under dev.ucp.common.*, reusable by any vertical. Food Ordering remains a separate proposed Domain Tech Council charter (issue #518) aimed at restaurant and delivery flows, with no published namespace. In practice a supermarket is closer to a UCP retailer with locations; a restaurant needs primitives that do not exist yet.

Get ahead of the predictable Phase 1 primitives: expose live item and store-status availability, model your modifiers and required choices as clean, self-validating option trees, and make sure fees and fulfillment windows are machine-readable — before you integrate.