What Gets Lost Without a Record System
Every ranger who has worked anti-poaching for more than two seasons knows the problem. The arrest happens in a remote block — Block 4B, say, at first light, three men with wire snares and a freshly killed bushbuck. You radio in, you process them at the station, and the paperwork is done by hand. Six months later, one of those men comes through again. Different team on shift. Nobody remembers the face. The previous arrest record is in a physical file somewhere, if it hasn't been mislaid, and nobody is cross-referencing it against the new arrest in real time.
That is not a record-keeping failure — it is an intelligence failure. And it costs species.
The anti-poaching context is merciless about data quality. A poacher who has been arrested twice for ivory possession and is flagged as a potential informer represents a completely different tactical situation than a first-time trespasser from a neighboring village. Treating both the same because the historical data isn't surfaced quickly is the kind of mistake that undermines prosecutions, loses informer leads, and allows repeat offenders to operate with impunity. The paper station register doesn't solve this. A centralized suspect database does.
The Fields That Actually Drive Prosecution
The "Born (automatic calculation)" field — a relativeTimeStr(#{Birthday}) calc — seems trivial until you're in court and the defense argues your documentation is sloppy. Having the age auto-calculated from the recorded birthday removes one transcription error from a process where every error can be exploited.
The charge categories multichoice field is where the operational value becomes tangible. The options span thirteen distinct categories: wildlife trapping, trespass, possession of firearm, possession of poison, killing mammals or birds or fish, arson, violence against an officer, possession of traps, possession of bushmeat, and possession of ivory or horn. These aren't arbitrary — each maps to a specific provision under the relevant parks and wildlife act. A ranger who captures this data correctly during processing is building a prosecutable record, not just a narrative. When you filter across 200 arrests by "Possession of Ivory/Horn" combined with "Possession of firearm," you are identifying the high-end commercial poaching tier — the people connected to buyers. That filter doesn't work on a narrative report. It works on structured data.
The Block (arrest location) choice field — running 1A through 10B — ties every arrest to a patrol grid sector. Over time, this tells you which blocks have the highest arrest density, whether that's driven by terrain, patrol frequency, or active poacher networks operating out of adjacent communities. The "Locations & locstats" list field adds a second layer: arrest site, crime scene, carcass location. Those are three different coordinates with three different forensic implications, and keeping them distinct matters when you're building a prosecution case or re-briefing a new patrol team before they enter that block.
The interrogation section is the most operationally sophisticated part of the template. It's split between Primary Questions (for Live Intel) and Secondary Questions (Passive Intel) — a distinction that reflects real questioning doctrine. Primary questions focus on immediate actionable intelligence: who planned the operation, what was the entry and exit route, who is the buyer, where did the weapons come from. Secondary questions operate at a softer register: why did you start, how do you choose when to enter, what do you think happens to poachers who are caught. The passive intel questions are diagnostic — they tell you about community attitudes, deterrence effectiveness, and the suspect's psychological profile relative to informer potential. Both sections have a "LIVE INTEL" flag field, meaning a ranger can mark during processing if the suspect has given information requiring immediate operational follow-up, before the full debrief is even complete.
When the Database Has Two Hundred Arrests
At fifty records, a suspect database is a contact list with extra fields. At two hundred, it becomes an intelligence picture.
The "Previous wildlife convictions" and "All past convictions/warrants/legal-proceedings" list fields are separate for a reason. Wildlife convictions tell you about pattern of behavior within the park ecosystem. General criminal history tells you about the individual's risk profile more broadly — someone with a violence-against-officer conviction from another jurisdiction is a materially different operational risk than a repeat bushmeat snarer.
The linked libraries — Suspect Charges and Suspect Compensation — pull in via Link To Entry. This means the charge records aren't free text buried in a case note; they are structured entries from a shared library, meaning every charge carries consistent terminology and every compensation figure is computed from the same species-valuation table. When a prosecutor reviews cases, they're looking at standardized data, not six rangers' six different ways of writing "elephant poaching." That consistency is what allows the database to function as legal documentation rather than just internal operational notes.
The "Informer potential" boolean and accompanying "Informer conversion details" field appear twice — once in the primary questions section, once in the secondary. That's intentional. A suspect's informer potential can shift significantly between initial processing and a follow-up secondary interview. Recording both assessments separately creates a longitudinal read on the individual's disposition, which is exactly what a handler needs when deciding whether to pursue conversion.