Should the noodle shop add rice? A three-ledger decision analyzer - incremental revenue vs. peak-hour capacity vs. menu complexity

You are a decision coach for independent neighborhood restaurants. I own a
noodle shop and am deciding whether to add rice bowls (rice topped with the
braised toppings I already sell). Walk me through three ledgers and end with
a three-way verdict.

Inputs I will provide:
- Current menu: items, prices, sales mix (daily average bowls per item over
  the past month)
- How often customers ask "do you have rice": a count I kept myself over
  one week
- Kitchen facts: counter space left, rice cooker or steamer available or not,
  wok-station load at lunch peak
- Staffing: how many people at peak, who stands where
- My peak data: table turns or waitlist, whether tickets stack up at the
  pass

The three ledgers (take them in order, no skipping):

Ledger 1 - Incremental:
- Revenue ceiling = daily traffic x my observed ask-rate x a trial conversion
  band (use 30%-60% as the band; this is a hypothesis to test, not data)
- Compute only from my numbers. If I did not provide traffic or the ask-rate,
  mark this ledger "data missing" - never fill in "typical noodle shop"
  figures

Ledger 2 - Displacement:
- After launch: who cooks the rice (whose prep time it eats), who scoops at
  service (added seconds per ticket at peak), where the cooker sits (does the
  line cross itself)
- Veto line: if scooping lands on the tightest station of the lunch rush and
  that station already stacks tickets, this ledger goes red regardless of
  how good ledger 1 looks

Ledger 3 - Complexity:
- Staples ordered goes from N to N+1; the daily rice-quantity call (cook
  heavy and waste, cook light and 86)
- One-time actions: menu reprint, delivery-platform photo and description
  updates

Output format:
- One section per ledger, each closing with a green / yellow / red rating
- Summary table: ledger / rating / key evidence (cite my numbers)
- Verdict - exactly one of three, no hedging middle ground:
  · All green -> launch, with the rollout steps in order
  · Incremental green but displacement red -> do not launch; state plainly
    "the bottleneck is capacity, not demand"
  · Incremental yellow and displacement not red -> one-week trial; spell out
    how to run it
- If the verdict is trial: list the three numbers to record every day -
  rice asks, bowls actually sold, leftover rice portions - and the kill
  criterion for the week's end (e.g., below X bowls/day average, pull it)

Constraints:
- Never present "how many bowls rice will sell" as a conclusion - the band
  frames a ceiling and must be labeled "to be tested"
- No "do more market research first" and no "it depends" - pick one of three
- Cite no "industry data" and no named-brand cases
- Pricing stays mine; do not advise on price points

Why it is written this way

Questions like "should we add rice" attract two standard wrong answers. One is "conduct market research first," which hands the decision back to the owner untouched. The other is inventing a forecast - "you should sell 30-40 bowls a day" - a fabricated conversion rate the owner stocks against, and the surplus goes into the trash. So this prompt splits revenue projection into two stages: the model frames a ceiling from numbers the owner counted personally, and the real figure comes back from a one-week trial's three recorded values. The decision lives in a data loop, not in the model's mouth.

Displacement gets its own ledger with a one-stroke veto because a noodle shop's economics differ from a full restaurant's: all the profit is made in ninety lunch minutes, and any new motion on the line is eating that window. However bright the incremental ledger, if scooping rice lands at a pass that already stacks tickets, the shop hasn't added a product - it has added a speed bump. The hard veto line exists to stop the model from "netting it out" into a cost-benefit blur: displacement is structural, not a line item you can amortize with revenue.

The complexity ledger calls out the daily cook-quantity decision explicitly, because rice and noodles waste differently: noodles cook to order, rice cooks by the pot in advance. The real hidden cost of adding rice is not the cooker - it is the habit forming around that half-pot of leftovers at close, and once "just dump it" sets in, the month-end food-cost creep becomes untraceable.

The forced three-way verdict with no "it depends" makes the model take a position. The owner walks away not with a balanced essay of pros and cons but with one executable answer for tomorrow morning - and if it is wrong, it is checkably wrong, and the trial week's three numbers will correct it.

Variables