# Chomp Donuts — Design-Partner Recipe & Costing Reference

**What this is:** a real design-partner kitchen's real recipes, with a competitor's (MarginEdge)
costing as ground truth. It's our most important product-credibility artifact: proof that Mise
costs actual restaurant food, and matches the incumbent to the penny on the same real invoices,
before it does the things the incumbent can't.

**The chef in the loop:** Chomp Donuts (Park City, UT), one of Jeff's design-partner kitchens.
Jeff is the chef who adjudicates ambiguous prices (e.g., whether a specialty pectin really costs
$157/kg). This is the "top chefs teach it and grade its answers" loop, made concrete.

## The two files (do not confuse them)

- `chomp-test/chomp-recipes-INPUT.html` — the recipes **without costs**. This is what the app is
  fed. Safe to demo, test, and walk through the X-ray flow with.
- `chomp-test/chomp-answer-key.md` — the **private grading sheet**: MarginEdge's costed sheets
  built from Chomp's real invoice prices, with every line and total backed out. **Never feed this
  to the app.** It exists only to check the app's output against known-correct answers.

## The costing model (confirmed against MarginEdge, and it IS our playbook)

MarginEdge exposed its own math on the shells line, and it matches our engine spec exactly:

```
1. sub-recipe unit cost = batch cost ÷ batch yield        ($56.3937 ÷ 22,670 g = $0.0025/g)
2. line cost            = unit cost × quantity            ($0.0025 × 65 g   = $0.1617)
3. apply yield (divides): effective = line cost ÷ (yield%/100)   ($0.1617 ÷ 0.90 = $0.1797)
4. round to 2 decimals at DISPLAY only                    ($0.1797 → $0.18)
```

Yield **divides**. Rounding is display-only, never mid-calc. The cost column is the **line total**
(unit price = line total ÷ qty). These are the same rules that govern the legacy port.

## Ground-truth checkpoints (the "is it right?" numbers)

Like the fixtures cost to ravioli 198¢ / pancakes 143¢, the Chomp set has known-correct totals:

| Recipe | Correct total |
|---|---|
| Strawberry Jam (sub, 11,612 g batch) | **$85.03** |
| Salted Caramel (sub, 8,960 g / 256 fl oz batch) | **$19.46** |
| Vanilla Bean Pastry Cream (sub, 13,617 g batch) | **$98.63** |
| Undecorated Shells/Rings (sub, 22,670 g batch) | **$56.3937** → $0.0025/g |
| **Salted Caramel Donut** (finished, $3.75 menu) | **$0.40 plate cost · 10.7% food cost** |

## The crown-jewel demo: the Salted Caramel Donut

This one dish exercises the whole engine and the whole product story at once:
**2-level sub-recipe recursion + a dual-unit sub (consumed in fl oz) + the only 90% yield in the
dish + full margin math** ($0.40 ÷ $3.75 = 10.7%). It is the ideal flagship for the F5 "living
answer" frame — a chef sees a real menu item costed to the penny, every line x-rayed to its
source, margin shown, in seconds. If one recipe goes in a demo or a test, it's this one.

## Edge cases baked in — these map straight to the X-ray frames

These aren't noise; they ARE the test, and each one is a moment the verify/x-ray flow exists for:

- **Same ingredient, two units:** vanilla beans appear as "12 **g**" in the caramel and "24 **each**"
  in the pastry cream. The each↔weight question should fire on the "each" one. (F3 verify.)
- **Price outliers the guard should surface, not swallow:** pectin $157.81/kg, cocoa butter
  $68.50/kg, frozen strawberries $6.10/kg. All plausibly real specialty prices — **Jeff
  adjudicates** — so the product should flag them for review with market context, never silently
  absorb them. (F3 verify, the dollar gate.)
- **The 90% yield trap:** the shells are the only yield application in the donut. Apply 100% by
  default and the donut lands at ~$0.39 instead of $0.40 — a correct-*looking* miss that only the
  yield explains. This is exactly why every number must carry its ledger.
- **All other yields are 100%:** tests that we correctly do NOT flag a pastry filling the way we'd
  flag produce.
- **Only the donut has a menu price ($3.75):** so it's the only recipe that tests margin end to end.

## Two tests — do not conflate (this is the most common misread)

1. **Engine math (Test A):** feed the engine the backed-out unit prices from the answer key. It
   must reproduce every line and total **to the penny** ($85.03, $19.46, $98.63, $0.40, 10.7%). A
   miss here is an engine bug. This is the real known-cost test, and it's a CTO/engine gate.
2. **Data/matching (Test B):** run the full pipeline against our own corpus. Costs **will** differ —
   these are Chomp's Park City invoice prices, and Utah has no corpus density. A different total is
   **not** a bug. Only gross mismatches (wrong ingredient matched, price 10× off) are bugs. Never
   benchmark a corpus run against these totals.

## Why this matters for product

- **Credibility:** we cost a real chef's real menu and match the category incumbent exactly. That's
  the "at least as good, then we do more" proof the whole positioning rests on.
- **The demo:** the donut is the most persuasive single artifact we have for the F5 living answer.
- **The honesty principles have real material to prove themselves on:** the outliers, the yield
  trap, and the unit ambiguity are precisely where "every number carries its ledger" and "surface
  gaps honestly" either earn or lose a chef's trust.