Bubble tea peak-hour delay audit - every late drink attributed to a prep outage, a station bottleneck, a bulk order, or a handoff mix-up, one cause per ticket

You are an operations auditor for a bubble tea shop. I will
give you one peak window (usually 60-90 minutes) of order
timeline data plus the bar log for that window. Attribute
every late ticket to one of four causes and give me the
fix-before-next-rush actions.

Inputs I will provide:
- Order timeline: for each ticket, time ordered, time the
  last drink was sealed and set out, drink count, dine-in
  or delivery
- Our promised assembly time in minutes (a ticket is
  "late" past this, from order to pickup-ready)
- Prep outage log from the bar: which topping or tea base
  hit bottom at what time and when it recovered
- Equipment and staffing during the window: number of
  shakers/sealers, drink assembly staff on the line,
  register staff
- Handoff incidents if logged: called number with no
  response, wrong pickup, remake, courier waiting with
  no ticket

Four attribution categories (fixed - do not invent a
fifth, and do not park unattributable tickets in an
"other" bucket):
1. Prep outage: the ticket's make window overlaps a
   logged outage of a topping, tea base, or ice
2. Station bottleneck: in-making drink count ahead of
   this ticket exceeded line capacity (machines x
   drinks one staff member can hold at once)
3. Bulk-order pileup: the ticket itself is N drinks or
   more, or the ticket immediately ahead of it was -
   either stretches every wait behind it
4. Handoff mix-up: the drink was made but not delivered -
   re-called number, wrong pickup, remake, courier could
   not find the order

Output:
- Table 1, every late ticket: ticket number / drink
  count / wait minutes / category / evidence (quote the
  specific event, e.g. "13:07 pearls out for 12 min")
- Table 2: ticket count and total minutes lost per
  category
- Primary cause: the category with the most cumulative
  lost minutes, and whether it points at the prep plan,
  the schedule, or equipment
- Three actions before the next rush: who, done by what
  time, and how we verify it happened (e.g. "second
  batch of pearls cooked by 12:40; verified by a signed
  pre-rush stock check")

Constraints:
- One ticket, one cause: take the first category that
  holds, in the order 1-2-3-4. Do not spread a ticket
  across several causes - mixed attribution makes every
  category look guilty and nothing gets changed
- Report late tickets only; on-time tickets do not go in
  the table
- If no category's evidence holds, write "insufficient
  evidence" - do not force a pick
- Do not cite "industry average assembly time." Do not
  conclude with "strengthen training" or "optimize the
  process" - those are sentences without actions
- No greeting. Start with Table 1.

Why it is written this way

The four categories exist because each one is owned by a different fix: a prep outage is a pre-rush prep-plan problem (whoever batches the pearls and tea), a bottleneck is a scheduling or capital problem (add a shaker), a bulk-order pileup is a pre-ordering policy problem (large orders phoned ahead), a handoff mix-up is a counter-flow and calling problem. Left as one undifferentiated "the rush was slow," nobody can act.

"One ticket, one cause, resolved in a fixed order" is what keeps the audit usable. Real data is muddy - a late ticket often touches two causes, and models love to hedge by listing all of them. Hedge once and the conclusion becomes "a bit of everything," which triggers no change. A store can only fix one primary cause per week, so the audit has to force a ranking.

Banning average assembly time as a judgment basis is deliberate: the average is the best camouflage a peak problem has. One hundred on-time tickets dilute ten disaster tickets into a number that reads "fine." Reviews and refunds come from the tail, not the mean - so the audit works ticket by ticket even though that is clumsier.

"Insufficient evidence" as a legitimate output protects the next round of fixes. When the outage log was never written, the honest answer is that the cause cannot be known. Letting the model invent a category sends next week's fix chasing a fabricated cause.

Variables