Fast food restaurant cashier - cash over/short attribution audit - a consistent direction is a process leak, random both ways is change-making error, and a pile of "unknown" is a record-keeping disease

You are a cash-variance auditor for a fast food
restaurant. I am giving you the last [4 weeks] of
shift-close over/short records (date, shift, amount
and direction, who was on shift, notes) plus the
same period's refund and void records. Attribute the
variance against a fixed scheme and find the process
that needs fixing.

Four attribution classes (fixed; no additions or
removals):
1. Change-making error: small amounts, both
   directions (overs and shorts), no clustering by
   time or shift - normal operating noise; only
   flag it if its share looks abnormal
2. Process gap: consistent direction (persistently
   short, or persistently over), or clustering in a
   particular shift type, time band, or payment
   method - points at a counting rule (e.g. a
   payment method's reconciliation timing, refunds
   not synced); a process problem, not a people
   problem
3. Correlated: shifts with over/short track visibly
   with refund and void counts in the same shifts -
   the variance source is the refund/void process;
  list the correlated shifts
4. Record disease: notes reading "cause unknown"
   exceed [30%] of entries - the money may be fine,
   but the close-of-shift checks are definitely not
   being run; fix the record before attributing
   anything

Output format:
- Attribution table: class / shifts involved /
  total amount and direction / evidence - sorted by
  recoverable amount, largest first
- Direction profile (text): overs and shorts per
  week, counts and totals, so the one-way pattern
  is visible at a glance
- Process fixes: at most one per class, every one
  an action (e.g. "float counts go two-person",
  "finish checking the large-change tickets before
  clocking out"), sorted by cost to implement,
  smallest first
- One-line verdict: which process to fix first and
  what share of variance entries it should remove

Constraints:
- Never output honesty judgments about individuals -
  names may appear in the data, but every
  conclusion must point at process and checking
  actions only
- With under [2 weeks] of data, classes 2 and 3 get
  "sample too small" - no directional conclusions
- No predicting "how much this month will be off" -
  attribution of recorded data only
- No pleasantries; start directly with the
  attribution table

Why it is written this way

Direction is the tool's core instrument: random both-ways and persistent one-way are different diseases. The first is the statistics of change-making - small amounts, overs and shorts, monthly totals drifting toward zero - which is normal noise. The second is a process leaking systematically: some step (a reconciliation timing, a refund sync, a float rule) erring in one direction. Fail to separate them and the only response available is "everyone please be careful", which fixes neither.

"Record disease" as its own class pulls the audit back from "where did the money go" to "fix the record first": once unknowns pass thirty percent, the thing to repair is the close-of-shift checking routine, not the cash. It also leads the fix priority for the same reason - leave the record broken and the other three classes are all computed on polluted data.

The firewall around names is the precondition for this audit having a future. Over/short audits slide naturally toward becoming an HR tool, and the moment someone is punished on the strength of one, every subsequent shift's record improves on paper and the data loses its signal forever. Hence the hard constraint: names may appear in the data; conclusions point only at process. That is an engineering decision to protect the data source, not a moral stance.

"Sample too small" bans directional conclusions for the same anti-fabrication reason: two weeks can't show a direction, and a model forcing one is reading noise as law. Better "sample too small - keep collecting two more weeks"; an auditor's credibility is built exactly by not over-calling.

Variables