Officer Elena Reyes sits at a workstation at 11:42 PM with a twelve-minute body-worn camera (BWC) recording, a computer-aided dispatch (CAD) entry noting "disturbance, possible weapon, 2142 Garfield," and a draft from the AI tool her agency deployed six weeks ago. The draft reads well. It flows. It uses the passive voice in the right places and is laid out in the structure her agency's records management system (RMS) expects. She has thirty minutes before the end of shift. The temptation is to read it through, agree it sounds right, and submit. But she has been through this course. She knows what a "generic helpful assistant" sounds like when it is generating a police narrative, and she knows it is not the same thing as what a careful, methodical report writer produces. The difference is not style. The difference is discipline: a careful report writer does not fill gaps. They note them. They do not reach for boilerplate. They describe what happened. They do not write with fluency for its own sake. They write with precision because the document is evidence.

Why the Default Model Posture Is Wrong for Police Reports

A large language model trained on general text is optimized to be helpful. In the broadest sense, helpful means producing a complete, coherent, fluent response to whatever the user asks. If you ask it to draft a report from an audio recording, it will produce a complete, coherent, fluent report. That is what helpful looks like from the model's perspective. The problem is that "complete, coherent, and fluent" is not the same thing as "accurate, grounded, and defensible." In fact, the qualities that make a general-purpose model pleasant to use are precisely the qualities that create legal risk in a sworn police narrative.

A helpful assistant fills gaps. A careful report writer leaves them and notes they exist. A helpful assistant rounds off ambiguous details into clean statements. A careful report writer uses qualified language: "appeared to be," "the subject stated words to the effect that," "audio quality degraded at this point." A helpful assistant reaches for common patterns when the specific data is thin. A careful report writer stops at the edge of what the footage shows. These are not minor stylistic differences. They are the difference between a report that holds up under cross-examination and one that gives a defense attorney a thread to pull.

Persona engineering is the practice of constraining the model's posture so that it writes like the careful report writer, not the helpful assistant. It works by giving the model an explicit role, explicit rules, and explicit limits built into the prompt itself. Those constraints travel with every request, which means every draft the model produces inherits the discipline. The officer does not have to manually fight the model's defaults on every sentence. The defaults have been changed.

The model's defaults make it a fluent gap-filler. Your job is to override those defaults and make it a disciplined evidence recorder before it writes a single word.

What Persona Engineering Actually Means in This Context

The term "persona engineering" sounds technical. In practice, it means writing a specific kind of instruction block at the top of your prompt before any case-specific content. That block does three things: it assigns the model a role, it states explicit behavioral rules, and it defines what the model must never do. When those three elements are present, the model's behavior on every request within that session is shaped by them.

The Role Assignment

The role assignment is the most important sentence in the prompt. It establishes the lens through which the model interprets every instruction and every piece of input that follows. A generic role assignment might say "You are a police report writing assistant." That is insufficient. It does not constrain the model's posture in any meaningful way. A well-constructed role assignment for evidence-standard report drafting says something more like this:

"You are a meticulous police report writer. Your only job is to describe, in precise, factual prose, what the provided recording and source materials show. You do not infer, extrapolate, or fill gaps. You do not use language that implies something happened unless the recording clearly shows it happened. You are not a creative writing assistant. You are not a summarizer. You are a transcription-and-description specialist who holds a court standard."

That role assignment does several things at once. It restricts the task definition (description only, not inference). It names the source of truth (the provided recording and source materials). It explicitly prohibits gap-filling. It names the standard (court standard). When the model reads that role before the recording transcript, its output changes. It becomes more likely to hedge, to use qualified language, and to note gaps rather than fill them. It is not perfect, and verification is still required, but the starting posture is fundamentally different.

Explicit Behavioral Rules

After the role assignment, a set of explicit behavioral rules narrows the model's behavior further. These rules should be specific and stated as prohibitions and requirements, not as aspirations. The language of "try to" and "please ensure" is weaker than the language of "never" and "always" when it comes to constraining a model's output. The rules for a police report persona might include the following:

Rule 1: Use only what the recording supports. Do not include any factual claim about what happened unless you can identify the specific timestamp or text in the source material that supports it. If you cannot identify the source, do not include the claim.

Rule 2: Report gaps honestly. If the recording does not clearly capture a moment, note that: "Audio unclear at [time]" or "Camera angle does not show [element] at [time]." Do not substitute a plausible inference for an honest acknowledgment of a gap.

Rule 3: Use qualified language for anything uncertain. Replace strong assertions with appropriately qualified language. "The subject appeared to reach for" rather than "the subject reached for." "The subject stated words to the effect that" rather than a direct quotation you cannot verify verbatim.

Rule 4: No use-of-force boilerplate. Do not use phrases that appear commonly in use-of-force narratives unless those phrases are directly supported by specific audio or visual evidence in this recording. Every use-of-force description must be drawn from this specific incident, not from the patterns of how use-of-force incidents are typically described.

Rule 5: Preserve sequence. The sequence of events in the narrative must match the sequence of events in the recording. Do not reorganize or condense in ways that change the temporal relationship between actions.

The Explicit Prohibitions

The prohibitions section is where you name the specific failure modes this lesson has been building toward. A model that has been told what not to do is harder to exploit than one that has only been told what to do. For police report persona engineering, the core prohibitions are:

Never invent a detail the source material does not contain. This is the gap-fill prohibition. It must be stated explicitly because the model's default behavior is to fill gaps when the source material is incomplete. That default is incompatible with a sworn narrative.

Never soften a fact. If the recording shows something unfavorable to the officer's account, the narrative does not "soften" it with qualifying language that diminishes its significance. The narrative describes what the recording shows. If the footage shows the officer saying something that will be subject to scrutiny, the narrative describes what the officer said, accurately.

Never fabricate a direct quote. Any language in quotation marks must be verbatim from the audio. If the audio cannot support verbatim accuracy, use paraphrase language. This prohibition addresses one of the three most dangerous failure modes in AI-assisted police reporting: the invented quote. An invented quote attributed to a subject is an immediate Brady problem, because Brady v. Maryland (1963) requires disclosure of all material evidence, and an inaccurate quote in a sworn report can be characterized as fabricated evidence.

Building the Persona Prompt: A Worked Example

Here is what a complete persona-engineering prompt looks like for a patrol officer drafting an incident report from BWC audio. This example is designed to be adapted, not copied verbatim, because the specific rules and emphasis will vary by incident type and agency policy.

The prompt opens with the role assignment: "You are a meticulous, evidence-bound police report writer working to a court standard. Your job is to describe in clear, factual prose only what the attached recording and source materials directly show or say. You are not a helpful general assistant. You are a precision instrument for translating an evidentiary record into a narrative."

It then states the source materials: "Your only sources are: (1) the attached BWC audio transcript, (2) the CAD entry text provided below, and (3) any direct observations I specifically note. You have no other sources. Do not use knowledge about how incidents of this type usually unfold."

It then states the rules, using the five rules above, framed as numbered constraints the model must follow for every sentence it produces.

It then states the output format: "Produce the report in the following sections: Dispatch Information, Arrival and Initial Contact, Course of Events [chronological, timestamped to the recording], Statements and Statements Summary, and Actions Taken. In the Course of Events section, include a timestamp reference for every claim."

It ends with the explicit prohibitions, stated as hard stops: "If you encounter a gap in the recording, note the gap. If you cannot source a claim, omit it and note 'source not found.' If the audio quality is degraded, note that. Do not fill gaps with plausible language."

This is a longer prompt than the default "write me a police report from this recording." The extra length is not overhead. It is the verification contract you have established with the model before the first word of the draft is written. Every sentence the model produces was produced under those constraints. That does not eliminate the need for the footage-grounded verification pass, which this program teaches in detail in the Level 2 lessons, but it shifts the baseline. Instead of starting with a draft full of confident assertions that may or may not be grounded, you start with a draft that has already flagged its own gaps and hedged its own uncertainties.

The System Prompt vs. the Per-Request Prompt

In most AI tools deployed by law enforcement agencies, there are two layers of instructions: the system prompt and the per-request (or "user") prompt. The system prompt is set by the agency, usually at the platform level, and applies to every interaction. The per-request prompt is what the officer types when drafting a specific report. Persona engineering can happen at both levels, and understanding the difference matters for operational practice.

Agency-Level System Prompts

The most powerful place for persona engineering is the system prompt, because it applies universally. An agency that has set an evidence-standard persona in its system prompt has built the discipline into the platform. Every officer who uses the tool, on every shift, gets a model that starts from the careful-report-writer posture without having to construct the persona themselves. The system prompt is the institutional version of the lesson in this module.

The CJIS (Criminal Justice Information Services) Security Policy governs data handling and system configuration for criminal justice information systems. That policy obligation sits with the agency, not the vendor. When an agency configures a system prompt, they are making an operational decision with evidentiary consequences. The system prompt should be reviewed by legal counsel, policy staff, and supervisors before deployment, and it should be documented as part of the agency's AI use policy. If the system prompt is ever challenged in court, the agency needs to be able to produce it, explain it, and defend its design.

Axon's Draft One, the AI report-writing tool integrated into the Axon body-camera ecosystem, includes system-level configuration that agencies can customize. The 82 percent decrease in report-writing time that testing officers reported is produced within a structured system that includes both system-level configuration and officer-level review. The persona built into that system, the constraints on what the model will and will not generate, is part of what produces a useful rather than a dangerous output. Understanding that design principle allows an agency to evaluate their specific deployment rather than accepting vendor defaults uncritically.

Per-Request Prompts for Officers

Where the agency system prompt is absent, inadequate, or not configurable, the officer must build the persona at the per-request level. This is more work, but it is available to any officer who understands the principle. The per-request persona prompt described above is an example of what that work looks like. The investment in writing a strong per-request persona pays off over many uses because the prompt can be reused. An officer who has developed a well-tested persona prompt for their most common incident types (traffic stops, disturbances, property crime) can apply it consistently without rewriting it from scratch each time.

The risk with per-request prompts is drift. An officer who is tired, rushed, or on a routine call may abbreviate the persona, skip the prohibitions, or default to a simpler prompt. That drift is where the risk accumulates. One of the practices that protects against drift is treating the persona prompt as a form: a specific, saved template that the officer opens, fills in the case-specific sections, and submits in full. The persona block should not be abbreviated because it feels redundant. It is not redundant. It is the discipline that travels with every output.

Testing Your Persona: Catching the Drift

A persona prompt is only as good as the outputs it produces. Before relying on a persona prompt in production, test it. Run the same audio or transcript through the model with and without the persona and compare the outputs. Look specifically for:

Gap-fills in the non-persona output. Does the model without the persona produce claims that are not in the source material? How many? What kind? Use-of-force boilerplate, scene descriptions, specific physical details? Now run the persona output. Does it produce fewer of those claims? Does it flag gaps? Does it hedge uncertainty? If the persona is working, the output should look substantially more conservative than the default.

Qualified language in the persona output. Does the persona output consistently use "appeared to," "stated words to the effect that," and similar qualifications for uncertain claims? Does it include timestamp references? Does it note audio gaps? If yes, the persona is functioning as designed.

Prohibited phrases in the persona output. Does the persona output still include use-of-force boilerplate that cannot be sourced to the specific recording? If yes, the persona prompt may need to be strengthened. Add the specific phrases you are seeing as explicit prohibitions. Name them: "Do not use the phrase 'threatening manner' or 'aggressive posture' unless the recording clearly shows the behavior those phrases describe."

This testing process is not a one-time activity. It is a regular check. Models update. Platforms update. An agency that deployed a system prompt in January and has not reviewed its output since then may be operating with a persona that has drifted from the intended behavior. The same review discipline that applies to individual reports applies to the prompts that generate them.

Persona Engineering and the Disclosure Obligation

One of the questions that arises when an agency implements persona engineering is whether the persona prompt itself needs to be disclosed. The answer is: probably yes, and certainly on demand.

Under Brady v. Maryland (1963), the prosecution must disclose all material evidence to the defense, including evidence that could be used to impeach the reliability of witness accounts or investigative materials. A police report drafted by an AI tool with a specific, constrained persona is a document whose production process is material to the assessment of its accuracy. The defense has a legitimate interest in understanding what instructions the model was given. An agency that cannot produce the system prompt or the per-request prompt when asked may find that the inability to produce it is itself used to argue the reliability of the report is questionable.

The Giglio v. United States (1972) obligation compounds this. Giglio requires disclosure of evidence that affects the credibility of a witness, including an officer. An officer who used a well-designed persona and ran the footage-grounded verification pass has a strong, documented case for the reliability of their report. An officer who used an uncontrolled tool with no persona, no verification, and no documentation has a weak one. The persona is not just a quality control measure. It is part of the disclosure record.

The King County, Washington, prosecutor's office barred AI-written police reports in part because there was insufficient transparency about how the AI was configured and what the human review process consisted of. A well-documented persona prompt, combined with a logged verification pass, addresses exactly the concern King County raised. The agency can say: "Here is the persona. Here is the constraint that says the model cannot fill gaps. Here is the officer's verification log. Here is where the officer corrected the draft. This is not a black box. This is a documented process." That answer is the difference between a court that admits the report and one that challenges its foundation.

The Electronic Frontier Foundation (EFF), which has raised transparency concerns about AI use in policing, specifically calls for documented, auditable processes. A persona prompt is part of that audit trail. Agencies that invest in persona engineering are not just protecting the quality of their reports. They are building the transparency infrastructure that preempts the most legitimate objections to AI-assisted policing.

Persona Engineering in Dispatch and Investigation Contexts

Persona engineering is not limited to patrol report writing. The same principle applies anywhere AI is generating or summarizing content that will enter the evidentiary chain.

Dispatch Summarization Personas

A telecommunicator (the formal title for a 911 dispatcher) using AI to summarize call audio for CAD entry faces a different but structurally identical problem. The model's default posture is to produce a clear, complete summary. The telecommunicator's requirement is to produce an accurate summary of what the caller actually said, not an inferred or completed version of what the call was about. A dispatch persona prompt constrains the model to the caller's words: "Summarize only what the caller explicitly stated. Do not infer call type from context. Do not add details not present in the audio. If the caller's language is unclear, note 'caller's intent unclear at [time].' Your output will be used as a CAD entry and will be reviewed by a telecommunicator."

The CAD entry is the first document in the chain of custody for an incident. An inaccurate CAD entry, produced by an AI that filled gaps in a chaotic call, affects every downstream document. The dispatch persona is the first quality control point in the pipeline.

Investigation Summary Personas

A detective using AI to summarize hours of recorded interview audio faces the problem at its highest stakes. Interview summaries are used to support search warrant applications, charging decisions, and case files. A fabricated or gap-filled quote in an interview summary is a Brady problem, a potential false-statement problem, and a case-ending error. The investigation persona prompt for interview summarization should be among the most restrictive in the agency's toolkit: "Summarize the interview using only statements the subject explicitly made, using the subject's own words where possible and close paraphrase where not. For every summary claim, cite the timestamp. If a portion of the recording is unclear, note it. Do not use inferred meaning. Do not summarize what the subject 'probably meant.' Describe only what the subject said."

That persona does not make the detective's job easy. It makes the detective's job accurate. The distinction is the one this entire program has been building toward: the time saving in the drafting is real, but the time saving is only valuable if the output it produces meets the evidence standard. A fast, wrong summary is worse than a slow, accurate one. The persona is what makes fast and accurate compatible.

Key Takeaways

• A large language model's default posture is to be a helpful, complete, fluent responder. In police reporting, that default is dangerous: it fills gaps, rounds off ambiguity, and reaches for boilerplate patterns. Persona engineering overrides those defaults before the first word is drafted.
• A strong persona prompt has three components: a precise role assignment that defines the model as an evidence-bound precision instrument, a set of explicit behavioral rules that constrain gap-filling, boilerplate use, and quote fabrication, and a set of explicit prohibitions that name the specific failure modes by their consequences.
• The most powerful place for persona engineering is the agency-level system prompt, because it applies universally to every officer who uses the tool. Per-request prompts are the fallback when system prompts are unavailable or inadequate, but they require consistent discipline to prevent drift on busy or routine shifts.
• Persona prompts must be tested by comparing persona-constrained outputs against default outputs. A working persona produces more conservative drafts with gaps noted, uncertainty qualified, and timestamps cited. A persona that is not producing those differences needs to be strengthened.
• The persona prompt is part of the disclosure record under Brady v. Maryland and Giglio v. United States. An agency that cannot produce its system prompt on demand has a transparency gap. A well-documented persona, combined with a logged verification pass, is the answer to the King County-style objection to AI-written reports.
• CJIS obligations for system configuration and data handling stay with the agency, not the vendor. The system prompt is an agency configuration decision with evidentiary consequences. It should be reviewed by legal counsel and documented as part of the agency's AI use policy.
• Persona engineering extends to every AI-assisted documentation task in the evidentiary chain: dispatch CAD entries, investigation interview summaries, and case documentation. The same principle applies everywhere the model's output will enter a sworn record or support a legal decision.
• The goal of persona engineering is not to produce a model that never needs verification. The footage-grounded verification pass is still required on every draft. The goal is to shift the model's baseline from "confident and gap-filled" to "precise and gap-flagging," so that the verification pass begins from a safer starting point.