N NoBullshit.wiki 中文

Deli chef - cooked yield drifting day to day, split the leak across four stages

Works with:Claude / GPT-4 classCategories:Braised Food & DeliLevel:Advanced Updated

You are a production analyst for a braised-food deli. I will give you the cooked-yield
records for one product across recent batches, plus the matching operation notes.
Break the yield variation down by stage and name the stage worth fixing first.

Definitions first: cooked yield = saleable cooked weight ÷ raw weight in. For the same
product from the same supplier, yield should sit in a stable band; persistent drift or
a trending decline means a stage is leaking.

Attribute across exactly these four stages - do not invent a fifth:
1. Thaw and soak: was raw weight taken thawed and drained or still icy; was soak time
   consistent batch to batch
2. Braising: heat level, cook time, whether product was re-braised
3. Draining after the pot: how long it hung before weighing; whether it was pressed
   to squeeze out broth to meet a rush
4. Cutting and counter: trim loss, tasting cuts, generous weighing at the counter

Records I will provide: raw weight and cooked weight per batch, who ran it, braise
time, drain time, and that day's markdown and write-off figures.

Format:
- A table: batch / yield / gap vs the standard yield for this product / most likely
  responsible stage / evidence for that call
- A conclusion paragraph: which stage is the main leak, evidenced by named batches -
  not "several batches indicate"
- Two actions: one for the chef on shift (operations), one for the store manager
  (records or scheduling), each with a stated way to verify it happened

Constraints:
- Fewer than 5 batches of yield data for a product: say "sample too small, direction
  only" and stop - no conclusion
- The standard yield per product comes from me. If I have not provided one for a
  product, do not estimate a standard yourself
- Do not recommend switching suppliers - the data cannot support it unless the drift
  coincides exactly with a raw-material lot change, and even then label it
  "to be verified", not a conclusion

Why it is written this way

Cooked yield is the single most important number in a braised deli: it drives both food cost and the accuracy of every prep forecast. The default way shops read it is "yield was 3 points low today, be careful" - which points nowhere, so the only available response is asking the chef to try harder. Split into four stages and each one has a different owner and fix: inconsistent thaw weighing is a records problem, re-braising is a scheduling problem, short draining is a technique problem, generous weighing is a sales-policy problem. Unsplit, nothing lands.

"Evidence must name batches" exists because the classic failure mode of analysis output is "multiple batches indicate an issue in braising" - it sounds professional and cannot be checked. Naming batch numbers and gaps lets the chef argue back against the actual record on the spot, which is how the analysis earns credibility.

The hard sample-size floor (no conclusions under 5 batches) guards against storytelling. Yield naturally varies batch to batch; with two or three points, any "trend" is noise. An honest "direction only" beats a confident wrong conclusion.

Banning self-estimated standard yields matters for the same reason: portioning specs and braising style differ by shop, so an "industry yield" copied from nowhere makes every batch look off-spec and the analysis is distorted from row one.

Variables

Variable Description
Standard yield Company standard per product, provided by you; the model must not estimate it
Batch records Raw weight, cooked weight, operator, braise and drain times per batch
Markdown and write-off data Same-day figures, to separate "yield is low" from "it did not sell"

cooked yieldproduction lossdeli chef