# Architecture Our menu structure is governed by the following key concepts: 1. Category and Sub-Category 2. Items 3. Option Groups 4. Options 5. Nested Option Groups and Options While each of them is described in the subsequent sections, here's a pictorial depiction of the architecture of the menu in our system: ![Hierarchy of the menu in our system](/files/VtMf5yFRx0mmXGyqA5GU) The above illustration shows the hierarchy of the menu structure in our system. There are basically two setups with categories - one where the subcategories are there and the other without any subcategory. The same is for items - one where the item is standalone and has no further customisations available and the other where customisations are available. More about Categories, Items, Option Groups, Options and Nested Option Groups and Nested Options are explained in the subsequent sections. {% embed url="" %} Menu Structure {% endembed %} In the above illustration, to the left panel, Categories and Subcategories are present. The Category - *"*What’s New : San Francisco Style*"* and Subcategory - *"Veg Pizza"*. Inside the Subcategory *"Veg Pizza"*, the item - *"Spiced Paneer"* has an Option Group - *"Size"*. This Option Group has 2 Options - *"Personal"* and *"Medium"*. Each one of the Options has a different Nested Option Group called - *"Base"*. Each Nested Option group has a Nested Option called - *"San Francisco Style Crust"*. The menu architecture also has another important underlying concept - the "federated" structure. For you to better grasp this concept we have put in an illustrative figure below: ![Illustration on the Federated Menu Structure](/files/PCcZe1Hyvcfomz5tDOfu) To understand the federated menu structure, let us take the above-illustrated example of an item called "Margherita Pizza" with an item ID "MAR". Let us say that the brand has 5 stores where this item is offered. Our system expects that this item should be created at the master level in the POS system and must carry the same menu ID across all the stores. This means that for all 5 stores the same item should be used based on the availability (the one with item ID "MAR") and the item should not be created again and again for different stores. The same item can have different prices and other possible store-wise varying attributes for different stores. However, the item ID should remain the same. This holds true for all the other elements like Category, Options Groups and Options as well. While there are several benefits to this structure one of the prime benefits is in the case of reporting. For a brand, it would be very easy to analyse the sales of the "Margherita Pizza" item since it is one item tagged to multiple stores. Just imagine the complexity in reporting if this item was created 5 times with different item IDs and then associated to each store! --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://api-docs.urbanpiper.com/downstream/menu/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.