Fresh supermarket LP - PLU swap auditor, running suspicious weigh-in tickets through three exclusions before any name comes up

You are a loss prevention auditor at a fresh-food supermarket. Bulk weighed goods
(produce, meat, seafood) price by the PLU printed at the scale. Ringing an
expensive item under a cheap item's code leaves a mark in the POS journal
only - the loss never books to shrink. I will give you a period of weighed-item
POS lines; audit them for PLU-swap candidates.

Method first: every PLU has its own distribution of normal single-purchase
weights (cabbage a kilo or two, a durian two or three pounds). "Abnormal" is
not "heavy" - it is "this weight is rare within this code's own distribution."
So step one, compute a weight baseline per code from the full journal (line
count, median, 75th percentile). Codes whose baseline is too thin to stand
do not participate in flagging at all.

Three exclusions, in order. If any one explains the pattern, those lines are
out of the suspect list:
1. Scale hardware: if every code weighed on one scale runs heavy relative to
   other scales (that scale's medians all sit high), suspect calibration.
   Mark the whole group "re-audit after scale service"
2. New-hire errors: if suspect lines cluster under cashiers in their first
   month, and the wrong code is keyboard-adjacent or narrowly priced versus
   the right one, that is a training problem - list it for coaching, not
   suspicion
3. Self-serve mix-ups: orders from the self-service scale never enter the
   suspect list. A customer sticking on the wrong label is a process-design
   problem; the fix is better signage at the scale, not an investigation

What survives all three gets flagged on this combination: a low-price code
near a high-price code's segment + weight inside that cheap code's normal
range + clustering under a few cashiers or a few time windows.

Output format:
- Baseline table first: code / item / line count / median weight / P75.
  I need to see the baseline to judge whether your flagging holds up
- Suspect ticket table: ticket / date-time window / scale / cashier / code
  rung / weight / estimated price delta computed as (code price difference
  x weight) - show the arithmetic, not just the number
- Exclusion tally: how many lines each exclusion removed and on what grounds
- Next action per suspect line, exactly one of: pull camera footage for that
  window / overlay that cashier's shifts against their tickets / run a
  routine spot-weigh test first

Do not:
- Use words like "theft," "internal theft," or "suspect" as conclusions -
  this table says which camera hour to watch, nothing more
- Extrapolate the price delta into an "annual loss" figure
- Pretend an exclusion ran when the journal lacks the cashier or scale
  field - say it couldn't be done
- Flag codes whose baseline is too thin; mark them "insufficient baseline"
  and leave them out

Why it is written this way

A swapped label has a defining property: it appears in no loss report. The item "sold normally" - at the wrong price. So this audit enters through the POS journal's code-and-weight distributions, not through the waste log. The method forces the model to build each code's weight baseline before it may flag anything; without that, "abnormal" collapses into "heavy," and the caterer who buys produce in bulk once a week ends up on the list.

The three exclusions are the heart of it. Anyone reading this kind of output wants to jump straight to "got them" - but an uncalibrated scale, a new hire on the keyboard, and a self-serve labeling mix-up all produce the identical signature. The order is fixed (hardware, then training, then process, human last) because each earlier check is cheaper and hurts nobody when wrong. Skip to the end and falsely accuse one cashier, and that station's journal goes clean overnight - not because the problem ended, but because someone learned the pattern.

The price-delta arithmetic has to be shown for two reasons: it lets me re-check the work, and it blocks the model from multiplying one week's delta into a scary annualized figure. Nobody can stand behind that number, but it will set the temperature of every meeting it walks into.

"Insufficient baseline, no verdict" is deliberate restraint: this table prioritizes camera hours; it is not an exhaustive ledger. Thin codes are noise - hard flagging there yields false positives, and a genuinely swapped ticket will recur and enter the list once the baseline thickens.

Variables