At 1:14 in the morning, in the patrol room of a mid-sized department, a draft lands in Officer Daniel Vega's queue. He has been on a single call for the last ninety minutes: a welfare check that became a trespass that became an arrest. He clipped his body-worn camera (BWC, the camera worn on the chest that records video and audio of the contact) back into its dock, and by the time he sat down, the report-drafting tool had already turned the audio into a clean two-page narrative. A small badge in the corner of the screen reads "AI draft ready for review." Vega has not read a word of it yet. The cursor blinks in the queue beside a single button: "Adopt." This lesson is about the few inches of screen between that draft and that button, because that gap is the most important piece of workflow design in the entire records pipeline, and almost nobody designs it on purpose.

The Handoff Is a Design Problem, Not a Button

When a department buys an AI report-drafting tool, the conversation is almost always about the front of the workflow: how fast the draft appears, how good it sounds, how much time it saves. Axon's Draft One, the most widely deployed tool of its kind, drafts a narrative from BWC audio, and testing officers reported an 82% decrease in report-writing time. Officers spend roughly 30 to 40% of a shift on paperwork, so the appeal is obvious and the savings are real.

But the front of the workflow is the easy part. The hard part, the part that determines whether the report survives a deposition and whether your agency survives a King County-style prosecutor objection, is the handoff: the precise moment and mechanism by which the AI stops being the writer and the human becomes the author. The handoff is where authorship transfers. If you do not design it deliberately, it designs itself, and it will design itself badly. It will collapse into a single button that an exhausted officer presses at 1:14 in the morning without reading, and at that moment the true author of a sworn legal document is a language model, and no one in the building intended that to be true.

This is the central claim of the lesson, and it is worth stating plainly. The sentence "the computer wrote it" must never be a true description of a report your agency files. The only reliable way to make that sentence false is to design the workflow so that it cannot be true: so that the human has to affirmatively act, in ways that are recorded, at checkpoints the system enforces, before the document can become a sworn report. You do not achieve this with a policy memo telling officers to be careful. You achieve it with structure.

Why a Policy Memo Is Not Enough

Every agency that deploys these tools writes a policy. The policy says the officer must review the draft, verify it against the footage, and adopt it as their own. That policy is correct and necessary, and it is also insufficient on its own, for a reason every working supervisor already understands: written policy describes the intended behavior, but the workflow shapes the actual behavior. If the path of least resistance is to click "Adopt" without reading, some officers will take that path, especially at the end of a long shift, especially on the fortieth report of a busy week.

Design closes the gap between the policy and the behavior. A well-designed handoff makes the careful path the easy path and makes the careless path impossible, or at least impossible to do silently. The goal is not to slow officers down for its own sake. The goal is to make the affirmative human act unavoidable and to make a record of it automatically, so that the document that leaves the workflow carries proof of its own authorship.

The handoff is the moment authorship transfers from the machine to the human. If you do not design that moment on purpose, it will collapse into a button, and the button will lie about who wrote the report.

Four Checkpoints Where the Human Must Act

A defensible handoff is not one moment. It is a short series of checkpoints, each requiring an affirmative human action, each leaving a trace. Think of them the way you think of a chain of custody: a series of documented transfers, each one accountable to a specific person at a specific time. The point of the chain is not bureaucracy. The point is that at any later date, anyone can reconstruct exactly who handled the evidence, when, and what they did with it. The officer-AI handoff deserves the same rigor, because the report is evidence.

Here are the four checkpoints. They map onto Officer Vega's 1:14 a.m. moment, and they turn the single "Adopt" button into a sequence that cannot be passed through accidentally.

Checkpoint One: Receipt and Labeling

The first checkpoint is the draft's arrival. The moment the AI produces a draft, the system should label it unmistakably as AI-generated and not-yet-reviewed. This sounds trivial. It is not. A draft that looks identical to a finished human report invites the officer's brain to treat it as finished. The labeling is a design choice that resets the officer's mental stance from "approve this report" to "review this proposal."

Good labeling does three things. It marks the document's status as a draft, not a report. It identifies the tool and version that produced it, which matters later for disclosure and for understanding the draft's known failure modes. And it records the source materials the draft was built from: which BWC clip, which CAD (computer-aided dispatch, the system that logs the call for service with its timestamps) entry, which audio. That source list is the officer's verification map. You cannot verify a draft against the record if you do not know which part of the record the draft claims to be based on.

Checkpoint Two: The Review Pass

The second checkpoint is the verification itself, the systematic read of the draft against the primary record. This is the substance of the officer's work, and it is covered in depth in the lessons on the footage-grounded verification pass and on reviewing and adopting an AI draft. For the purposes of handoff design, the relevant question is not how the officer verifies but whether the workflow gives the verification room to happen and evidence that it happened.

A workflow that drops the officer directly onto an "Adopt" button has designed the verification out of existence. A workflow that requires the officer to move through the draft, to interact with each section, to acknowledge that each factual claim has been checked, has designed the verification in. The difference is whether the interface treats review as the default activity or as an optional speed bump on the way to submission. The review pass is the job now. The interface should make that obvious.

Checkpoint Three: Correction and Attribution

The third checkpoint is correction. When the officer finds something wrong, and on any nontrivial report they will, the workflow should capture the change, not just the corrected text. This is where the design starts to produce the audit trail. A system that lets the officer edit freely and silently is a system that erases the evidence of the officer's authorship. A system that records what the AI proposed, what the officer changed it to, and when, is building the record that defends the report later.

This is a subtle but powerful design principle. The corrections are not a sign that the tool failed. The corrections are the affirmative proof that the human was the author. An officer who can show "the draft said the apartment was in disarray; I corrected it to reflect that the footage showed an orderly room; here is the timestamp of that edit" has produced the single most persuasive possible answer to the question of who wrote the report. The edit history is not a liability. It is the asset. Design the workflow to keep it.

Checkpoint Four: Affirmative Adoption

The fourth and final checkpoint is adoption, the act that converts a reviewed draft into a sworn report. This is the moment the entire handoff exists to protect, and it deserves the most deliberate design of all. Adoption should be an affirmative act, not a default. It should require the officer to do something that is meaningfully different from clicking "next." And it should record the officer's attestation, in the officer's name, with a timestamp.

The strongest design pattern here is an explicit adoption statement that the officer affirms by a deliberate action. A typical formulation reads: "I have reviewed this AI-generated draft against the body-worn camera footage, the CAD entry, and my own observations. I have verified and corrected the narrative, and I adopt it as my sworn account of this incident." When the officer affirms that statement, the system records the statement, the officer's identity, the time, the tool and version, and the source materials. That bundle is the proof of authorship. It is what turns "did a computer write this?" into a question with a documented, defensible answer.

Designing So "The Computer Wrote It" Can Never Be True

Now we can be precise about the lesson's title claim. To make "the computer wrote it" impossible to say truthfully, the workflow must satisfy four conditions, and each one is a design requirement, not a behavioral hope.

Condition one: the human act must be unavoidable. There can be no path from draft to filed report that skips the affirmative human action. If an officer can submit a report without affirming adoption, the workflow permits machine-authored documents, regardless of what the policy says. The submit-without-review path must simply not exist.

Condition two: the human act must be meaningful, not a rubber stamp. A single checkbox at the bottom of a long form is technically an affirmative act, but it is a weak one, because it is too easy to do without engaging. Stronger designs tie the attestation to evidence of actual review: the officer cannot affirm adoption until they have moved through the draft, or until they have addressed each flagged gap, or until they have actively confirmed each high-risk claim. The design connects the attestation to the work.

Condition three: the human act must be recorded. The affirmation, the identity, the timestamp, the tool, the version, and the source materials must all be captured automatically and stored where they cannot be quietly altered. A human act that leaves no trace is, for legal purposes, nearly as bad as no act at all, because the officer cannot later prove it happened. The record is what carries the authorship forward in time, to the deposition that may occur two years later.

Condition four: the AI's contribution must be distinguishable. The workflow should retain a clear picture of what the AI proposed and what the human changed. This is the part agencies most often skip, and it is the part that most powerfully establishes authorship. If the only thing that survives is the final text, you have lost the story of how the text came to be. If the draft, the edits, and the final coexist in the record, the authorship is legible to anyone who needs to see it.

The Anti-Pattern: The Invisible Handoff

The most common failure is what we can call the invisible handoff: a workflow in which the draft appears and the officer approves it, and nothing in the record distinguishes a careful review from a reflexive click. In the invisible handoff, the draft and the final report are the same document, the adoption is a single button, and the system stores no evidence of what the officer did between receipt and submission. The report that comes out is indistinguishable from a machine-authored document, and when a defense attorney asks the officer to prove they reviewed it, the officer has nothing but their word.

The invisible handoff is not the result of bad intentions. It is the result of no design. It is what you get when the procurement conversation focused entirely on the speed of the draft and never on the structure of the review. The Electronic Frontier Foundation (EFF), a digital-rights organization, has raised exactly this transparency concern about AI-drafted police reports: that the public and criminal defendants have a legitimate interest in knowing when a government document that can deprive a person of liberty was generated by an automated system. The invisible handoff makes that concern unanswerable. A designed handoff answers it directly, with a record.

The Audit Trail as the Deposition Answer

Everything in the designed handoff exists to produce one artifact: an audit trail that survives to the day someone challenges the report. Picture Officer Vega two years after that 1:14 a.m. arrest, in a deposition chair, facing a defense attorney who has done their homework. The attorney asks: "Officer, this report was drafted by an artificial intelligence system. Did you write it, or did the computer?"

If Vega's department deployed the invisible handoff, he is in trouble. He can say he reviewed it, but he cannot prove it, and the attorney can probe until "I reviewed it" frays into "I read through it and it looked right," which is not a review that a sworn report requires. If the attorney can show a single fact in the report that Vega could not have personally observed and did not catch, the attorney has an opening to argue that Vega does not actually know what is in the document he swore to.

If Vega's department designed the handoff well, the deposition goes differently. The audit trail shows the draft as the AI produced it, the timestamp when Vega received it, the duration of his review, the specific corrections he made (the disarray edit, a corrected arrival time pulled from the CAD entry, a quote he fixed against the audio), and the adoption attestation he affirmed at 1:31 a.m. with the source materials listed. Vega can answer: "I am the author of this report. I received an AI-generated draft, reviewed it against the body-worn camera footage and the CAD entry, corrected three items the draft got wrong, and adopted it as my sworn account. Here is the record of that review." That answer is not bravado. It is documentation. The authorship is real because the workflow made it real and kept the proof.

What the Audit Trail Must Contain

A handoff audit trail that does its job in a deposition or a discovery dispute should contain, at minimum, the following:

• The AI tool and version that produced the draft, so the draft's known behavior and failure modes are identifiable.
• The source materials the draft was built from: the specific BWC clips, the CAD entry, any audio or attached documents.
• The draft as the AI originally produced it, preserved separately from the final report.
• The officer's corrections, captured as changes from the draft to the final, ideally with timestamps.
• The review duration or activity, evidence that the officer engaged with the draft rather than passing through it.
• The adoption attestation: the statement, the officer's identity, and the timestamp of the affirmative act.

None of this is exotic. Much of it is metadata the systems already generate; the design task is to capture it, bind it to the report, and store it where it cannot be silently changed. The Criminal Justice Information Services (CJIS) Security Policy, the FBI-maintained policy that governs how criminal justice information is handled, places the obligation for proper data handling on the agency, not the vendor. That obligation extends to the audit trail. The agency that cannot produce a defensible record of how its AI-assisted reports were authored has a CJIS-adjacent governance gap, not just a workflow inconvenience.

Disclosure Lives in the Handoff

The handoff is also where disclosure gets designed in or designed out. Brady v. Maryland (the constitutional requirement that the prosecution disclose material exculpatory evidence to the defense) and Giglio v. United States (which extends that duty to evidence that could impeach a witness, including the testifying officer) together make the question of how a report was written a matter of constitutional disclosure, not just internal practice. If a report was AI-drafted, the fact of that assistance and the record of the review may be discoverable.

A workflow that captures the audit trail makes disclosure a matter of producing a record that already exists. A workflow that captured nothing makes disclosure a matter of officers reconstructing, from memory, what they did months or years earlier. The King County, Washington prosecutor's office drew a hard line in 2025, barring AI-written police reports from its charging process absent specific documentation of the review. The designed handoff is precisely the documentation that line demands. The agency that built the handoff well can hand the prosecutor a clean record; the agency that did not is asking its officers to defend an undocumented process in court.

Building the Handoff in Your Agency

You may not control the vendor's interface. Many agencies have signed bundled, multi-year, sole-vendor contracts that lock in a particular tool, and the officer or supervisor reading this cannot redesign the software. That is a real constraint, and it does not excuse the invisible handoff. The handoff is a workflow you can build around the tool you have, using the agency's own process, even when the software does not enforce it for you.

Where the Software Helps and Where It Does Not

Start by being honest about what your tool does and does not do at each of the four checkpoints. Does it label drafts clearly as AI-generated? Does it preserve the original draft separately from the final report? Does it record edits? Does it capture an adoption attestation with a timestamp? For each "no," you have a gap that the agency's procedure has to fill manually until the software catches up or you negotiate a change at the next contract review.

Where the software does not preserve the original draft, agency procedure can require the officer to save it. Where the software does not capture an adoption attestation, the agency can add an adoption statement to its report-approval step and log it. Where the software does not record review time, the agency can require a field-notes entry documenting the review. None of these manual measures is as clean as software that enforces the checkpoint, but every one of them converts an invisible handoff into a visible one, and a visible handoff is what defends the report.

The Supervisor's Role in the Handoff

The handoff does not end with the officer. The supervisor who approves reports is a second human checkpoint, and a well-designed workflow uses that checkpoint deliberately. A supervisor who approves AI-assisted reports without any indication of how the underlying review was performed is rubber-stamping the same way an officer who clicks "Adopt" without reading is. A supervisor whose approval step surfaces the audit trail, who can see that the officer engaged with the draft and made corrections, is adding a real layer of accountability.

This is also where patterns become visible. A supervisor reviewing the audit trails across a shift can see the officer who adopts every draft in under thirty seconds with zero edits, which is a near-certain sign of the invisible handoff happening one officer at a time. The audit trail is not only a deposition asset. It is a supervision tool that lets a sergeant catch a dangerous habit before it produces a report that fails in court.

Designing the Statement Officers Will Actually Affirm

The adoption statement is the keystone, and it should be written with care. A statement that is vague ("I have reviewed this report") is weak, because it claims little and proves less. A statement that is specific about what the officer did ("I reviewed this AI-generated draft against the BWC footage and the CAD entry, verified the factual claims, corrected the narrative where needed, and adopt it as my sworn account") is strong, because it describes a real process the officer either did or did not perform.

The statement must also be honest, which means officers have to actually do what it says before they affirm it. A statement that officers affirm reflexively without performing the review is worse than no statement, because it manufactures false evidence of a review that did not happen, and a defense attorney who exposes that gap damages not just the one report but the officer's credibility across every case. The design lesson is that the statement and the work have to be bound together. Affirming the statement should be the last act of a real review, not a substitute for one. That binding is the whole point of designing the handoff: making the human act unavoidable, meaningful, recorded, and true.

Key Takeaways

• The officer-AI handoff is the moment authorship transfers from the machine to the human, and it is a design problem. If you do not design it deliberately, it collapses into a single "Adopt" button that an exhausted officer presses without reading, making a language model the true author of a sworn legal document.
• A policy telling officers to review carefully is necessary but insufficient. Workflow design, not a memo, is what closes the gap between intended behavior and actual behavior by making the careful path the easy path and the careless path impossible to take silently.
• A defensible handoff has four checkpoints, each requiring an affirmative recorded human action: receipt and labeling, the review pass, correction and attribution, and affirmative adoption.
• To make "the computer wrote it" impossible to say truthfully, the human act must be unavoidable (no submit-without-review path), meaningful (tied to evidence of real review, not a reflexive checkbox), recorded (identity, timestamp, tool, sources), and distinguishable (the AI's draft preserved separately from the human's corrections).
• The officer's corrections are not a sign the tool failed; they are the affirmative proof the human was the author. The edit history is the asset, not the liability, and the workflow should be designed to keep it.
• The audit trail exists to produce the deposition answer. An officer with a documented record of receipt, review, corrections, and a timestamped adoption attestation can answer "did a computer write this?" with proof rather than just their word.
• The handoff is where disclosure is designed in or out. Brady, Giglio, the King County prosecutor's bar, and CJIS data-handling obligations all turn on whether the agency can produce a clean record of how an AI-assisted report was authored and reviewed.
• You can build the handoff around a vendor tool you do not control. Where the software fails to label, preserve, record, or attest, agency procedure can fill the gap manually, and a visible handoff, even a manual one, is what defends the report when the invisible handoff would have failed.