Section 7: One Machine, Every Salad - Deep Dive: Recipes, Customization & Price Integrity

Executive Summary: This section opens the box the whole topic has been pointing at: the resolution algorithm that turns a recipe reference plus a delta into a concrete, priceable ingredient list, with every business rule enforced server-side (D2/D3). We price order #1042 step by step, state and defend the removals-refund-nothing product rule, show that build-your-own is the same machine with an empty recipe, roll nutrition and allergens up from the resolved list with legal honesty (D11), and nail down the price-change-mid-cart contract: reprice against the current version, surface the delta, never silently charge more. Two pushbacks close it out — why structured deltas beat POS-ticket text, and why "charge for removals someday" costs the model nothing.

The interviewer taps the whiteboard where you wrote "server prices everything" and says: "Prove it. Maya removes blue cheese, adds avocado, doubles the chicken. Walk me through exactly what the server does — no hand-waving." This is the moment the topic's central bet — the ingredient is the atom (D1) — either pays compound interest or gets called in. The answer is one algorithm, and everything else in this section is that algorithm wearing different hats.

The Resolution Algorithm, Precisely

Resolution is a pure function: (recipe, delta, menu_version, availability) → resolved list. Four steps, each with a rule the server — never the client — enforces.

Step 1 — Load the recipe's ingredient set. From v47, Harvest Cobb is a set of ingredient references, each carrying a quantity and the required/default flag Section 5 called the most leveraged bit in the schema. This is the starting state: romaine (required), chicken ×1 (required), blue cheese (default), and the rest.

Step 2 — Apply the delta, validating every operation. The delta is intent (D2); intent can be stale, malformed, or hostile, so each operation faces a rule:

• Removes must reference a present ingredient. remove: ["blue-cheese"] is legal because blue cheese is in the loaded set and it is a default, not a requirement. Removing romaine from a Cobb would be rejected — the recipe loses its identity without it. Removing an ingredient that was never there is a validation error, not a no-op: a client that sends it is desynced, and silence would hide that bug.
• Adds must be orderable at this location — an active ingredient in v47, not currently 86'd in the availability overlay. An add of an 86'd ingredient is rejected with substitution suggestions: same category, similar price (avocado down? offer fresh mozzarella from the premium category at a comparable price point). The failure has a UX, not just a status code.
• Quantity changes are capped. quantity: {"chicken": 2} passes; {"chicken": 9} does not. Caps are per-ingredient business rules living server-side — the kitchen physically cannot fit nine portions of chicken in one bowl, and the model should know what the bowl knows.

Note what "extra" means here: a quantity, not a string. "Extra chicken" is quantity: 2 — a quantity can be priced, capped, resolved, and rolled into nutrition; the string "extra" can only be printed and prayed over.

Step 3 — Emit the resolved list. Harvest Cobb's set, minus blue cheese, plus avocado, chicken at 2. This list — not the recipe, not the delta — is what pricing, nutrition, allergens, and the kitchen consume.

Step 4 — Price it and stamp it. Preset pricing is the base plus the sum of priced adds, minus nothing:

Harvest Cobb base               $11.95
+ add avocado                   + $2.00
+ chicken quantity 1 → 2        + $3.50
− remove blue cheese            − $0.00   (product rule, stated below)
                                -------
Total                           $17.45

The result is stamped with menu_version: 47 and frozen into the order's snapshot (D4) — the price list the money was judged against, named forever.

Quick check before moving on: