Convenience store security supervisor - monthly security-system function test checklist: cameras verified by doing something on camera and playing it back ten minutes later, alarms tested only by the monitoring station's agreed procedure with the receipt kept, rear doors tried one by one for lock and closer, drive space and host clock checked monthly - equipment that was installed is not equipment that still works

You are a convenience store security consultant.
I am the security supervisor over [number of
stores] stores. Produce a printable Monthly
Security-System Function Test Checklist. The
checklist's bar is not "is the equipment there"
but "does it still work" - a lit camera feed and
a panic button that signals when pressed are two
different facts, and only the second one can be
learned by testing.

Input I will provide:
- Per store equipment: number of camera
  channels and recorder location / alarm device
  type and position (monitored alarm / in-store
  sounder / remote fob) / number of rear doors /
  door contacts yes-no
- Monitoring-station arrangement: who the alarm
  reports to, the agreed test procedure and
  window (items with no arrangement are marked
  "confirm before testing")
- Our retention requirement: [retention period]

Test framework:
T1 Recording and playback (three channels per
   store: entrance, register, rear door)
   - Action: perform two visible actions on
     camera (wave at the entrance / place one
     item on the register counter), note the
     time, play back ten minutes later
   - Pass: both actions found in playback;
     timestamp within two minutes of real
     time; the image resolvable enough for
     that channel's purpose
   - Same pass checks: drive space remaining;
     earliest playback date no shorter than
     our retention requirement; recorder
     host clock date
T2 Alarm devices
   - Action: one test per the procedure and
     window agreed with the monitoring station
   - Pass: the station receives the signal and
     issues an acknowledgment or log entry
   - Where no arrangement exists, do not press
     anything on your own - get the
     arrangement first; the item is marked
     "confirm before testing"
T3 Rear doors and locks (door by door)
   - Action: open once from outside, confirm
     it auto-locks on release, watch whether
     the closer pulls the door fully shut,
     check the door gap for wedge marks;
     where a door contact exists, trigger it
     once and confirm the host logs it
   - Pass: opens normally from outside,
     locks on release, door fully closed, no
     wedge marks, contact event logged
T4 Register area
   - Is the panic button's position blocked by
     stock - a button buried behind boxes
     equals no button
   - Safe (if present): date of the most
     recent code change falls within the
     registered rotation window

Every item carries six elements: test object /
test action (who, how, how many minutes) / pass
bar / who gets the same-day repair call on
failure / retest bar / tester's signature.

Output:
- Checklist body (T1-T4, copied per store)
- Monthly test log template: store / item /
  date / result / tester
- Failure tracking table: store / item / repair
  reported / repair completed / retest result;
  anything still unrepaired when the month
  rolls over is auto-flagged "escalate" - the
  one action in this checklist that leaves
  store level and goes up

Prohibitions:
- Do not invent an external rule that "alarms
  must be tested monthly" - frequency and
  method follow the monitoring-station
  arrangement; the checklist fixes only "if
  tested, it is logged"
- Retention period is not a generic number -
  it is derived from this store's count and
  reconciliation cycle (I supply it in the
  input)
- No equipment brands or models; repair calls
  go to a role (equipment technician / security
  vendor), never a company name
- Every result is pass / fail / not tested -
  no "running fine," no "broadly normal"
- No "regular inspections" or "continued
  monitoring" without a frequency; no polite
  preamble - start at T1

Why it is written this way

The checklist's bar is "does it still work," not "is it there," because security equipment fails silently: a lit camera indicator proves nothing about recording, a recorder that records proves nothing about retention, a button in place proves nothing about the signal path - every one of those failures stays invisible until the day the equipment is needed for real. A blind-spot self-audit answers whether the camera sees the right thing; this checklist answers whether the system still functions. Only both together make the equipment layer whole.

T1 is tested by doing two actions on camera and playing them back ten minutes later, not by glancing at the live view. Live view proves the lens is alive, not that footage records and retrieves - and after an incident, what is wanted is never the live view, it is playback. Waving at the entrance and placing an item on the counter give playback a decidable target: finding both actions proves recording; matching timestamps prove retrievability. The host clock check rides along in the same pass - a half-hour clock skew and the footage never lines up with the POS journal, which makes it nearly worthless in a dispute; calibrating monthly costs nothing.

"No agreed procedure, no self-test" is the one item allowed to sit empty. Pressing a monitored panic button as a test sends a real signal - it wakes the monitoring station and triggers their false-alarm handling, and the test itself becomes the incident. So "confirm before testing" is designed as a normal state, not a defect: better an empty line this month than a genuine alarm manufactured for the sake of a complete table.

The tracking table's auto-escalate on month-old failures gives the checklist its one path upward. Repairs sink at store level - the store forwards the ticket and considers the matter closed, and whether it was ever fixed goes unchased; auto-flagging unrepaired items as "escalate" is what breaks the test-monthly, log-monthly, broken-monthly loop. It is also why repair calls name roles instead of vendors: the checklist should outlive any change of supplier, its test actions and pass bars independent of the contract.

Variables