What a restaurant menu loses under v2026-08-25 - a reproducible baseline for the Menu Catalog work

[amitkssolanki]

Update (Sept 12, 2026): This analysis has produced its first spec proposal: @J-tt's Nested Options (#821), which makes the unrepresentable-items class exportable. A measured evaluation of that proposal against the same 12 reference menus (via menuconform export --target nested-options-821) is posted on #821. The analysis below is unchanged and still applies to the shipped v2026-08-25 catalog model.

With the Food Tech Council seated and Lodging's capability landing (#780), I wanted to contribute a concrete, reproducible baseline for the Phase 2 Menu Catalog discussion: what happens when you map a real restaurant menu onto the current shopping catalog shapes (product/variant/product_option/price) as of v2026-08-25.

I built an Apache-2.0 conformance kit, menuconform, that validates restaurant menus against a food-domain IR - designed from a field study of the public menu models of Uber Eats, DoorDash, Grubhub, Checkmate, and the NCR Voyix Menu API (the kit ships an NCR importer), and pressure-tested against the Square Catalog, Toast Menus, and Clover Inventory APIs - and then exports to the pinned UCP catalog schemas, reporting every loss with stable rule IDs. Running its full-feature reference menu - one that scores 100/100 on menu-data conformance - through the export yields one item that cannot be represented at all and eighteen lossy constructs. Reproduce with:

menuconform export fixtures/02_full_feature/menu.json

The losses cluster into five classes (full analysis: docs/export-lossiness.md):

1. Customization itself. The only modifier structure that survives is a required single-select with fixed prices (a size), which maps cleanly to options/variants. Optional/multi-select groups, per-option quantities, "first N free," and nested groups drop entirely - the exported product is orderable but uncustomizable. When a required group can't become a variant axis, the item can't exist: the reference menu's family combo (pick-a-side, pick-a-drink, priced upgrades) is unrepresentable. Enumeration is not the workaround - a modest item with two required 8-option choices already needs 64 variants; a real pizza needs millions.
2. Cross-selection pricing. Topping-by-size matrices and combo upsells priced by base size condition one selection's price on another - outside the variant model by construction.
3. Half/half. Fractional portions with proportional/full/max pricing: core pizza economics, no representation.
4. Safety-critical data. No allergen field, no age-restriction field on catalog items; dietary claims degrade to free-text tags. An agent filtering "no peanuts" gets silence, not safety.
5. Time. Dayparts, seasonal windows, holiday exceptions, and timed 86ing all drop; the catalog is timeless.

Credit where due: integer minor-unit prices, availability, and single-select sizes map exactly.

The kit's IR already specifies and tests each missing construct (two-axis selection constraints, conditional prices, included quantities with pinned allocation, slots, structured allergens/age, recurring + exception schedules) across 12 fixture menus with pinned expected findings - offered as evidence of what real menus require and as a candidate test corpus for Phase 2, not as a proposal for its shape. The linked analysis also catalogs pricing constructs beyond the IR's own list - position-based topping ladders, removal credits, prep-code multipliers, fractional-portion multipliers - that the charter's implementer companies ship in production today. As far as I can tell there's no public food sample menu in the ecosystem yet; the fixtures are Apache-2.0 if useful. Happy to run the export against any draft schema the council produces and report what changes.

[J-tt]

Hi @amitkssolanki I've put forth a proposal that I hopes addresses some of these concerns, I know it will not satisfy all of them but I'd love to hear your feedback #821

[amitkssolanki]

Thanks for taking this forward @J-tt. Nested Options addresses the largest loss class measured here, and rather than reply with opinions I wired menuconform up to your proposed shape and re-ran the 12 reference menus against it: the family combo becomes representable and correctly priced, the remaining losses land exactly on your declared non-goals, and the depth cap is the one new constraint the corpus trips. Full evaluation with numbers posted on #821.