Patrol
Patrol is ERPat's security-operations module. It replaces the paper guard logbook and scattered spreadsheets with one connected, digital system where every entry is reference-numbered, time-stamped, and tamper-evident. Security teams record what happened, who came and went, and what was investigated — and can later prove those records were never quietly altered.
What Patrol is
Guardhouses have always run on a paper logbook — a bound notebook where each shift writes what it observed. Paper is easy to lose, hard to search, and impossible to trust after the fact: a page can be torn out, back-dated, or rewritten. Patrol keeps the same familiar workflow (a guard logs an event, a visitor checks in, an incident is raised) but makes each record durable and defensible.
- Reference-numbered. Every record gets a human-readable number the moment it is first saved — a blotter entry is
EVT-2026-0042, an incidentINC-2026-0007, a visitVIS-2026-0311, a handoverHND-…, a patrol runRUN-…, a public reportPSR-…. - Append-only. Submitted records are never edited in place. Correcting one creates a new version (v2, v3…) with a stated reason, while the original text stays byte-for-byte intact and viewable.
- Tamper-evident. Records are linked into a daily hash chain. A nightly check re-walks the chain, so any deletion, re-ordering, or silent edit is detected and flagged as a critical alert.
- Privacy by design. Visitor records intentionally hold no government-ID number, ID scan, or date of birth — only a "photo ID visually verified" checkbox. Public reporters can stay anonymous, and their contact details are minimised.
Who it is for
Patrol is built for the people who run day-to-day physical security and the managers and officers accountable for it:
- Guards & front-desk officers — log activity, check visitors in and out, run patrol rounds, and hand over their post at end of shift.
- Shift supervisors & security managers — see who is on duty now, raise and investigate incidents, acknowledge handovers, and review the blotter.
- Investigators & evidence custodians — manage the incident register, attach evidence, and keep an unbroken chain of custody.
- Administrators & the Data Protection Officer (DPO) — configure locations, permissions, retention policies, legal holds, data-subject requests, and the disclosure log.
- Residents & the public — submit a security concern from a public web page with no account, then track it privately with a one-time code.
Why it matters
Nothing gets lost
Every observation, visit, and incident is searchable by reference number, date, site, and category — instead of leafing through a notebook.
Records you can defend
Append-only versioning plus the hash chain let you show a record was not altered — valuable for insurance claims, HR cases, and law-enforcement referrals.
Privacy built in
Sensitive identifiers are simply not collected, PII is redacted before any AI call, and retention and legal-hold controls support data-privacy obligations.
One connected picture
Blotter, visitors, incidents, shifts, rounds, assets, and public reports share sites, people, and handovers — so a shift change or an investigation pulls the live state together automatically.
What's inside — the capability map
Patrol appears as a single Patrol group in the left menu; each capability below is one menu item whose page hosts its sub-features as tabs. Every area is gated by its own permission, so you grant staff exactly the parts of the module they need. Full walk-throughs live in Daily Operations and Administration.
| Capability | What it does | Menu item | Access permission |
|---|---|---|---|
| Dashboard | At-a-glance security overview and entry point. | Dashboard | patrol_dashboard |
| Activity Log / Blotter | The searchable, reference-numbered digital logbook with photo evidence and escalate-to-incident. | Activity Log | patrol_log |
| Visitor Management | Check-in → check-out with live occupancy, overstay flags, pre-registration invites (QR), and visitor passes. | Visitors | patrol_visitor |
| Incident Register & Evidence | Formal 8-state incident lifecycle, restricted / legal-hold controls, evidence with hash-chained chain-of-custody, people & follow-up tasks. | Incidents | patrol_incident |
| Shifts & Guards | Shift roster, guard records, license-expiry tracking, and an "On Duty Now" panel that reads live core Attendance. | Shifts | patrol_shift |
| Handover | Append-only end-of-shift endorsements that auto-capture open incidents and visitors still inside. | Handover | patrol_handover |
| Patrol Rounds | Execute routes by scanning checkpoints (start → scan → complete), capture observations, and flag missed rounds. | Rounds | patrol_run |
| Routes & Checkpoints | Build patrol routes and printable, server-validated checkpoint scan codes. | Routes | patrol_route |
| Assets & Equipment | Register radios, keys, vehicles and more; issue → return with condition tracking and overdue alerts. | Assets | patrol_asset |
| Reports & Exports | Daily Activity Report (CSV) and Incident Register (PDF), reusing the same data as the live screens. | Reports | patrol_report_export |
| Public Reports (triage) | Staff queue for concerns submitted through the public reporting page; correspond, set status, and convert to an incident. | Public Reports | patrol_public_report_triage |
| Locations | The physical hierarchy — sites, zones, gates, and posts — that routes, shifts, and rounds hang off. | Locations | patrol_location |
| Governance | Retention policies, legal holds, data-subject (DSAR) requests, and the disclosure log — the compliance layer. | Governance | patrol_retention |
| AI-assist Ships OFF | Optional, human-in-the-loop incident suggestions (draft / classify / briefing). Never writes records on its own. | AI | patrol_ai |
How records stay trustworthy
Two ideas run through the whole module. You don't operate them by hand — they work automatically — but understanding them explains why Patrol behaves the way it does.
- Versioned amendments. Once a record is submitted it is locked. "Editing" it saves a brand-new version and marks the old one superseded, keeping a full amendment history with reasons. Lists show only the current version; open a specific version to read exactly what it said.
- The daily hash chain. Blotter entries, incidents, and handovers are cryptographically linked in date-bucketed chains. The nightly chain-verify job re-walks each chain and raises a critical alert if any link is broken — the digital equivalent of proving no page was torn out of the logbook.
Evidence goes a step further: each evidence item records a content fingerprint (SHA-256) and its own append-only custody ledger (collected → transferred → checked out/in → disclosed/destroyed), so you can always show where a piece of evidence has been. See Daily Operations for how this looks in practice.
Where it lives in ERPat
- Left menu → Security → Patrol. The module sits in the Security area (directly after Kiosk). Turn it on in Settings → Manage Modules (the
module_patroltoggle); until then it is invisible. - Public reporting page. Residents and the public reach the intake form at
/patrol-report(or/patrol-report/{company‑key}for a specific tenant). It needs no login: they submit a concern and receive a one-time tracking code to follow its status privately. - Built on core ERPat. Patrol reuses the platform's file storage (local / AWS S3), audit log (system logs), notifications, and — for "who's on duty" — the core Attendance clock-in, rather than rebuilding them.
- Self-contained per tenant. Each company's data lives in its own database; a single default site (Main Site) is created when the module is first installed.
Ships off, or needs setup first
A few capabilities are intentionally dormant on day one so the module never does anything surprising or destructive until an administrator opts in:
| Feature | State on install | To activate |
|---|---|---|
| AI-assist | OFF — the AI menu item is hidden and the page shows a disabled notice. | Turn on module_patrol_ai, then an admin accepts the one-time data-privacy (DPA) acknowledgement. AI only ever suggests; a human must approve and apply. |
| Retention policies | Needs setup — four placeholder policies ship inactive with a blank retention period, so nothing is ever deleted. | The DPO sets a retention period and activates a policy in Governance. The nightly sweep then anonymises, soft-deletes, or purges — always excluding anything under legal hold. |
| Incident alerts | Needs setup — the "incident raised" / "escalated" notification events exist but have no default recipients. | Assign recipients in Settings → Notifications. Until then, alerts are raised but nobody is notified (by design, to avoid noise). |
This guide — document map
The rest of the Patrol documentation is organised for different jobs. Start wherever fits your role:
Enable the module, grant permissions, set up your first site, and make your first blotter entry. ⏱ Daily Operations
Step-by-step SOPs for guards and supervisors: logging events, checking visitors in/out, raising incidents, running rounds, and shift handover. ⚙ Administration
Permissions, settings and toggles, locations, notifications, governance / retention, AI setup, and the scheduled background jobs. ▤ Data & Screen Reference
Every screen, field, status value, reference-number prefix, permission key, and report explained. ◈ Research & Evidence
The live-file evidence behind this guide: the controllers, models, migrations, and jobs each claim is grounded in. ? FAQ & Troubleshooting
Common questions, a glossary, and how to resolve the issues teams hit most often.