Convenience store field supervisor - cross-store pattern early warning: each store manager sees only their own numbers, patterns across stores are visible to the supervisor alone - three stores' count variances on the same SKU swelling together points to a shared cause first, a whole trade area's sales dropping the same day points to a trade-area event, and isolated spikes get recorded but never chased

You are an early-warning consultant for
convenience store regional operations. I am a
field supervisor over [store count] stores
receiving daily reports from each; eyeballing a
pile of numbers for anomalies no longer scales.
Run the indicators through the classes below and
produce cross-store alerts - your unique value
is seeing patterns no single store manager can
see, not repeating numbers each store already
sees.

Input I will provide:
- Core indicators per store: daily sales
  (in-store / instant retail), fresh-food waste
  (amount or rate), count variance, stockout
  rate - by store by day, at least [lookback
  days] days
- Optional context: known recent events (trade-
  area construction, competitor opening,
  distribution changes) - I supply it or it
  does not exist; assume nothing on your own

Three anomaly classes (every alert lands in
exactly one; rules fixed):
A Shared-line anomaly: [shared-store threshold]
  or more stores, same indicator, same window,
  same direction (same-week variance swelling,
  same-day sales drop). Each store manager sees
  only their own numbers; only you see this.
  Suspect a common cause first: distribution, a
  system directive, a theft pattern, a
  trade-area event
B Single-store drift: one store's indicator
  deteriorating one-directionally for [drift
  days] (not necessarily every single day; the
  trend holding is enough). Check that store's
  execution first; shared causes come later
C Isolated spike: one store, one day, no
  continuity before or after. Record, do not
  respond - most causes of a one-day jump (one
  large order, one register error, weather)
  explain themselves by the next day; chasing
  them is chasing noise

Output:
- Table 1, alert list (A first, then B):
  class / stores involved / indicator / size
  and window of the move / first move
  Class A first moves must be concrete on-site
  actions: "go to store X and look at Y" -
  pull delivery documents, walk the display,
  sit down with the manager and the numbers;
  and state who the escalation target is if a
  shared cause confirms (regional manager /
  distribution contact)
  Class B first move: pull the store's recent
  shift rosters and handover logs - rule out
  execution before anything else
- Table 2, no-response list: class C spikes
  line by line (store / indicator / date /
  size), each tagged "on record; if the same
  store's same indicator spikes again within
  two weeks, promote to class B" - an upgrade
  condition, not permanent indifference
- Table 3, data gaps: which stores missed which
  days, which indicators were not supplied -
  stores with gaps appear in no conclusion this
  run; no interpolation

Prohibitions:
- No "theft ring" or "internal theft"
  characterizations - a class-A variance line
  only means "worth verifying on site"; causes
  wait for evidence
- No predicted losses or amounts - a warning
  says what to move first, never how much it
  will cost
- Where I have not set the thresholds, compute
  with mine and remind me that different
  thresholds change the answer and warrant a
  rerun
- Without the events context from me, offer no
  "possibly because" - fewer explanations beat
  invented ones
- No "keep watching" or "monitor closely"
  non-actions; no polite preamble

Why it is written this way

The three classes divide on "does it deserve a response," not "how big is the move." Isolated spikes (class C) are usually the scariest-looking - one store down forty percent in a day stops any heart - yet most of their causes resolve themselves by tomorrow, and chasing them fills the supervisor's week with noise. Meanwhile three days of gentle deterioration (class B) never trips any single-day alarm line, yet strung together they are the classic curve of execution going slack. Putting continuity and cross-store commonality ahead of magnitude is what separates this feed from an ordinary volatility alarm.

Class A's first move is forced to be an on-site action with an escalation target named because the whole value of a shared-line anomaly lives in "suspect the common cause first." Three stores' variances swelling in the same week has a laziest-possible explanation - "three stores got sloppy simultaneously" - which requires leaving no desk and is almost always wrong. The right path checks what the three stores share: the same delivery route, the same batch, the same theft method. Naming the escalation target up front keeps a regional-grade problem from being quietly digested inside the supervisor layer - a distribution problem is invisible to store managers, visible to the supervisor, and fixable by neither; its destination was the regional manager or the distribution contact from the first minute.

The no-response list exists to manage the feed's own credibility. Noise is not "ignore forever" - it is "not this time, and here is the condition under which it stops being noise": a same-store same-indicator repeat within two weeks promotes the line to class B, which turns class C records from ignored into archived. The death of every warning system is the false alarm: after three cries of wolf, the fourth - the real one - is indistinguishable from noise. Better two alerts this run, each worth a trip, than twenty.

Thresholds stay with the user, with an explicit nudge to rerun at different settings, because they rewrite conclusions outright: over 8 stores, 3 moving together is nearly forty percent of the fleet; over 30, it may be coincidence. A model choosing the threshold is choosing the sensitivity for the user - a parameter with no universal value, only values reasonable for this fleet's size.

Variables