Sergeant Lena Farris finished the last sentence of her incident report at 11:47 p.m., copied the AI-generated draft into her RMS (records management system, the agency's central repository for case files and officer narratives), and filed it without re-reading the second paragraph. The next morning, the defense investigator flagged a sentence that described the suspect "aggressively gesturing" toward her partner. The body-worn camera (BWC, the officer-mounted video recorder that captured the encounter) showed no such gesture. The model had filled the gap. The narrative had not been grounded. And the tool that produced the draft had received no instruction telling it to stick exclusively to what the footage showed.

What a System Prompt Actually Is

A system prompt is a set of instructions given to an AI model before any user input arrives. Think of it as the standing orders the model reads before it opens its mouth. Every professional AI deployment, from the report-writing assistant embedded in a body-camera evidence platform to a standalone large-language model a detective uses to summarize case material, operates under some form of system prompt. The question is not whether a system prompt exists. The question is whether the one your agency relies on was written deliberately, with the evidentiary stakes of public-safety work locked into every line.

In consumer applications, a system prompt might say something like "You are a helpful assistant. Be friendly and concise." That instruction is fine for drafting a birthday message. It is catastrophically inadequate for drafting a sworn police report. The "helpful" instinct in a general-purpose model is precisely what produces the gap-fill detail: the model wants to give the officer a complete, polished narrative, so it fills in what a typical use-of-force encounter usually includes when the footage did not clearly show it. Helpfulness, when it is not constrained, is the adversary of accuracy in a legal document.

A public-safety system prompt must do four things that a general-purpose assistant prompt does not. First, it must bind the model to the source record: the body-worn camera footage, the CAD (computer-aided dispatch, the platform that logs incoming calls, assigns units, and timestamps every action during an incident) entry, the witness statements, and the case file. Second, it must prohibit inference, inference being any detail the model adds because it seems plausible rather than because it appears in the source. Third, it must embed the disclosure language that every AI-assisted document needs in order to satisfy agency policy and the Brady (Brady v. Maryland, the 1963 Supreme Court ruling requiring disclosure of exculpatory evidence to the defense) and Giglio (Giglio v. United States, the 1972 ruling requiring disclosure of evidence affecting witness credibility, including officer credibility) disclosure obligations. Fourth, it must set the tone and format to match what a sworn police report actually requires, not what a helpful assistant would naturally produce.

The system prompt is the one place where you set the guardrails once and every draft that follows inherits them. Get it right once. Get every draft right downstream.

The Anatomy of a Public-Safety System Prompt

A well-built system prompt for a public-safety report-writing context has six components, each addressing a distinct failure mode. Understanding what each component does and why the absence of it creates a specific legal risk makes it possible to evaluate any vendor-provided system prompt against the evidentiary standard, rather than accepting the default configuration.

Component one: identity and role. The model needs to know precisely what it is doing and for whom. "You are a police report drafting assistant" is not sufficient. The identity component should specify the legal character of the output: "You are assisting a sworn law-enforcement officer in drafting a factual narrative for an official incident report. This document will be disclosed to the defense, read in depositions, and may be entered as evidence at trial. Every sentence you produce must be supportable by the source materials provided." The identity component calibrates every subsequent output choice the model makes.

Component two: grounding constraint. This is the most important single line in any public-safety system prompt. It tells the model that the source record is the only basis for factual claims. A strong grounding constraint reads: "Base every factual statement in your draft exclusively on the materials provided in this session: the audio transcript, the footage description, the CAD entry, and any officer-supplied notes. Do not infer, extrapolate, or add details that are not explicitly present in those materials. If information required for a complete narrative is absent, write: [VERIFY: this detail was not captured in the provided materials] rather than filling the gap." The bracketed flag turns a hallucination risk into a visible, actionable review item. The reviewing officer does not have to hope the draft is complete. Every gap is labeled.

Component three: the inference prohibition. Related to but distinct from the grounding constraint, the inference prohibition addresses the specific failure mode where a model adds context that seems reasonable. Typical-incident knowledge is the enemy here. A model trained on thousands of police reports "knows" that a traffic stop that escalates to a DUI arrest usually includes a field sobriety test. If the officer's notes do not mention the sobriety test, a model without an inference prohibition may include it anyway, because it is statistically typical. The explicit prohibition reads: "Do not include any detail because it is typical of this incident type, consistent with general law-enforcement practice, or consistent with what you have seen in similar reports. Include a detail only if the provided materials contain it explicitly."

Component four: the disclosure boilerplate. Every report produced with AI assistance should carry a standardized disclosure statement that survives copy-paste into the RMS. The system prompt can instruct the model to append this automatically: "Append the following disclosure to the end of every draft narrative: 'NOTE: This narrative was generated with the assistance of an AI drafting tool. The reviewing officer has verified each factual claim against the source materials and adopts this narrative as their sworn account. The AI tool used was [TOOL NAME]. Review completed: [DATE/TIME].'" Embedding the disclosure in the system prompt means it cannot be forgotten. It means every draft that exits the tool arrives with the disclosure attached, and the officer's review and adoption are explicit acts rather than assumptions.

Component five: format and tone constraints. A sworn police report uses past tense, first person singular for the reporting officer, and third person for all other parties. It avoids characterizations ("the subject appeared nervous") unless the observable behavior that supports that characterization is also described ("the subject's hands were shaking and he made repeated eye contact with the vehicle's rear seat"). Embedding these constraints into the system prompt prevents the model from producing output that reads like a news article, a civilian narrative, or a press release. The format constraint should also specify what fields the output must populate: narrative, incident description, subject information, and any other RMS-required fields the agency uses.

Component six: output scope limitation. The scope limitation tells the model what it must not produce. "Do not provide legal analysis, advice on charging decisions, conclusions about probable cause, or assessments of the subject's credibility, intent, or guilt. Limit output to factual narrative elements drawn from the provided source materials." This component prevents the model from drifting into legal territory that requires attorney judgment, prosecutorial discretion, or sworn officer testimony about mental states that the officer observed directly.

Locking the Guardrails in Agency Policy

A well-written system prompt that lives only in an individual officer's personal AI account is not an agency guardrail. It is a personal habit that disappears when that officer transfers, retires, or uses a different device. For the system prompt to function as a governance tool, it must be locked at the agency level, reviewed by legal counsel and the prosecutor's office, versioned, and maintained.

The CJIS (Criminal Justice Information Services) Security Policy, administered by the FBI, governs how criminal justice information can be processed, stored, and transmitted. Any AI tool that touches incident data, report drafts, or case file material is processing CJIS-covered data. The agency's CJIS security officer should review and approve the system prompt as part of the AI tool's overall authorization, because the system prompt determines what the tool does with that data and what it can produce from it.

Locking the system prompt at the agency level also addresses a vendor risk that is worth naming directly. Several major public-safety AI vendors, including those offering bundled body-camera, drone, cloud, and AI packages on multi-year contracts worth tens of millions of dollars, provide default system prompts that are configured for general helpfulness rather than for evidentiary-standard output. When an agency signs a bundled contract, it may not have visibility into the system prompt running the AI drafting tool. Requiring the vendor to provide the full system prompt text, in the contract, with the right to modify it, is a procurement practice that agencies should adopt as standard. A contract that does not give the agency control over the system prompt is a contract that delegates authorship of sworn reports to a vendor's default configuration.

The King County, Washington, prosecutor's office made headlines when it announced it would not accept AI-written police reports. The underlying concern was not that AI was involved; it was that the office had no visibility into how the tool was configured, what instructions it was operating under, and how the output had been verified. A well-documented system prompt, combined with a clear verification and disclosure protocol, is the direct response to that concern. The prosecutor who knows exactly what the system prompt says, what it prohibits, and how the officer verified the output is in a fundamentally different position from the prosecutor who simply received a report and learned after the fact that AI was involved.

Testing and Iterating the System Prompt

A system prompt is not a one-time configuration. It is a living policy document that should be tested against real failure modes, updated when new failure patterns emerge, and reviewed any time the underlying AI tool is updated. The testing discipline for a public-safety system prompt follows the same logic as the testing discipline for any other operational policy: run it against the edge cases, not just the easy cases.

The basic testing protocol for a public-safety system prompt involves three categories of test inputs. First, test with incomplete materials: provide the model with a CAD entry and audio transcript that have obvious gaps, missing timestamps, or ambiguous events. A well-configured prompt should produce bracketed flags rather than gap-fill details. If the output fills the gaps without flagging, the grounding constraint needs tightening. Second, test with materials from a high-stakes incident type: use-of-force, pursuit, in-custody death, or officer-involved shooting. These are the incident types where fabricated details have the most catastrophic consequences, and they are the ones where the model's "helpful" instinct to produce a complete narrative is most dangerous. Third, test with materials that contain genuinely ambiguous information: an audio transcript where the subject's words are unclear, or a CAD entry where the call type changed mid-incident. The model should flag the ambiguity, not resolve it in favor of the most common interpretation.

The officers and supervisors who use the tool should have a formal mechanism for reporting when the system prompt produced unexpected or problematic output. This feedback loop is how the prompt gets better over time. It is also how the agency builds the documented record that demonstrates to prosecutors, oversight boards, and courts that the tool is being operated responsibly, with human oversight and an ongoing quality-improvement process.

Prompt iteration should be version-controlled. Every version of the system prompt should be saved with the date it went into effect, the reason for the change, and the approval authority. When a defense attorney subpoenas the system prompt used to produce a report from a specific date, the agency should be able to provide the exact version that was in effect on that date. That is not a hypothetical scenario. It is already happening in jurisdictions where AI-assisted reporting has been adopted for two or more years.

The Officer-Level Practice: Working Within the System Prompt

Understanding the system prompt from the officer's perspective means understanding what the prompt does and does not do for you. The system prompt constrains the model; it does not replace the officer's judgment about what happened at the scene. The two work together.

In practice, working within a well-configured system prompt means three things. First, it means providing the model with complete source materials before requesting a draft. A grounded system prompt can only be as good as the materials you give it. If you submit only a CAD entry and ask for a full narrative, the model operating under a strict grounding constraint will either produce a very thin draft or produce a draft full of [VERIFY] flags. Both outcomes are correct behavior from the model; they are telling you that the source materials were insufficient. The fix is not to adjust the prompt; it is to provide richer input, including your own field notes, the audio transcript, and any supporting documentation from the incident.

Second, working within the system prompt means reading the bracketed flags and acting on them. Each [VERIFY: this detail was not captured in the provided materials] flag is a specific instruction to go back to the source record and either confirm the detail or note its absence. An officer who skips the flags and submits the draft as filed has defeated the purpose of the constraint. The flag is the model doing its job; the officer who ignores it is the single point of failure.

Third, working within the system prompt means completing the adoption step. The disclosure boilerplate in the system prompt states that the officer "adopts this narrative as their sworn account." That language is not decorative. It means the officer has read every sentence, verified every fact against the source materials, corrected every error, and is prepared to testify to the contents of the report under oath. The adoption step is the moment when the AI draft becomes the officer's document. Before adoption, it is a machine-generated text. After adoption, it is a sworn statement. The review that happens between those two states is the officer's professional obligation, and no system prompt can substitute for it.

System Prompts and the Deposition Question

Every officer who uses an AI drafting tool should be able to answer the following deposition question clearly and honestly: "Officer, what instructions was the AI tool operating under when it produced the draft of this report?" The answer, in an agency with a well-governed system prompt, is straightforward: the tool was operating under a specific set of instructions that required every factual claim to be grounded in the provided source materials, prohibited the model from inferring or gap-filling, required a [VERIFY] flag wherever source materials were absent, appended a standard disclosure statement, and limited the model's output to factual narrative elements drawn from those materials. You reviewed every sentence against the body-camera footage and the CAD entry. You corrected three details that were inaccurate. You adopted the result as your sworn account and filed it with the disclosure statement attached.

That answer is defensible, transparent, and demonstrates exactly the kind of human oversight that distinguishes responsible AI use from a blindly accepted machine output. Compare it to the answer available without a governed system prompt: "The tool was using its default settings, which I did not review. I reviewed the output, but I am not sure exactly what instructions the model was operating under or what it was and was not permitted to infer."

Prosecutors, defense attorneys, judges, and oversight boards will increasingly ask about system prompts as AI in public safety becomes routine. The agencies and officers who have documented answers will be in a better position than those who do not. The system prompt is not merely a technical configuration; it is part of the evidentiary chain of custody for every document the tool produces.

Key Takeaways

• A system prompt is the standing instruction set that governs every output a model produces. In public-safety contexts, the system prompt must be built around the evidentiary standard, not general helpfulness, because every report it helps produce may be disclosed to the defense, read in depositions, and tested at trial.
• The six essential components of a public-safety system prompt are: identity and role, a grounding constraint binding the model to source materials, an inference prohibition, standardized disclosure boilerplate, format and tone constraints matching sworn-report requirements, and an output scope limitation preventing the model from producing legal analysis or credibility judgments.
• The grounding constraint is the most important single line in the prompt. It should require the model to insert a bracketed [VERIFY] flag wherever source materials are absent rather than filling the gap, turning a hallucination risk into a visible, actionable review item for the officer.
• Embedding disclosure language in the system prompt ensures that every draft exits the tool with the disclosure attached, making the officer's review and adoption of the narrative explicit acts recorded in the document itself.
• System prompts must be locked at the agency level, versioned, approved by legal counsel and the CJIS security officer, and made available to prosecutors as part of the AI tool's governance documentation. An officer's personal prompt configuration is not an agency safeguard.
• Agencies procuring bundled AI tools from public-safety vendors should require, in the contract, the full text of any system prompt governing the drafting tool and the right to modify it. Accepting a vendor's default configuration is delegating control over sworn-report authorship standards to the vendor.
• The officer's deposition answer about the system prompt should be specific, honest, and prepared: what instructions the tool was operating under, what the tool was prohibited from doing, and what the officer's own verification review covered.
• System prompts should be tested against incomplete materials, high-stakes incident types, and ambiguous inputs, updated when failure patterns emerge, and version-controlled so the exact configuration in effect for any given report can be documented and produced on demand.