Dispatcher Keisha Morales had 90 seconds. The caller was hysterical, the address was partial, and the call type had shifted three times in the first minute. Her AI transcription tool had captured every word. But when the time came to push a CAD (computer-aided dispatch, the platform that logs every call, assigns units, and timestamps every action across the incident) entry, the AI had returned a 280-word paragraph. No call type code. No unit recommendation field. No priority flag. Just confident, fluent prose describing a scene that the CAD system could not ingest and the RMS (records management system, the agency's central repository for case files, narratives, and evidence documentation) could not index. The AI had done its job. The integration had not been designed.

Why Prose Is Not Data

Public-safety AI tools are very good at producing prose. They are trained on millions of examples of coherent, professional writing, and when given incident material, they can produce polished narrative in seconds. This capability is genuinely valuable. It is also precisely mismatched with what the CAD and RMS systems require, unless the AI is explicitly instructed to produce structured output rather than free-form narrative.

Structured output means data formatted in a schema: a predictable arrangement of fields, values, and delimiters that a downstream computer system can parse, validate, and store without human intervention. The most common format used in modern AI integration for public safety is JSON (JavaScript Object Notation, a text format that represents data as named field-value pairs, readable by both humans and machines), though some agencies use XML, pipe-delimited flat files, or structured form objects depending on their CAD vendor.

A well-formed JSON output from an AI-assisted call summary might look like this: a field labeled "call_type" with a value matching the agency's call-type code list, a field labeled "priority" with a value of 1, 2, or 3, a field labeled "location" with a normalized address, and a field labeled "incident_summary" with a three-sentence factual description. That output can be validated against the schema before it ever reaches the CAD entry screen. If the call_type value is not on the allowed list, the system rejects it immediately. If the priority field is empty, the system requires a human to supply it. The validation layer exists between the AI and the system of record, and it catches the structural error before the error becomes a record.

Prose, by contrast, carries its errors invisibly inside natural language. A free-form paragraph describing a domestic disturbance does not tell the CAD system anything about priority, unit assignment, or call type. A human dispatcher still has to extract those values and enter them manually, which is the same workload the AI was supposed to reduce. Or, in the worst case, the free-form paragraph gets pasted directly into a notes field without extraction, and the critical call-type and priority data that downstream systems need for resource allocation and reporting never get populated.

If the AI output cannot be validated against the system schema before it reaches the record, the AI is a prose generator, not a system integration. Both have value; only one replaces human data entry.

The Anatomy of a CAD Structured-Output Prompt

Producing structured output that a CAD or RMS system can accept requires telling the AI exactly what fields to populate, what format each field requires, what the allowed values are for constrained fields, and what to do when a required field cannot be filled from the available source material.

The field specification is the foundation. Every CAD system has a schema, whether that schema is documented in the vendor's integration guide or discovered empirically through the agency's IT staff. The structured-output prompt must mirror that schema exactly. Field names must match. Data types must match. Constrained fields, those with a fixed set of allowed values, must enumerate the allowed values explicitly.

Consider a prompt designed for call entry in a mid-sized municipal CAD system. It specifies that the output must be valid JSON with the following fields: "incident_number" (populated from the CAD-generated ID, or left as null if not yet assigned), "call_type_code" (one of the values from a provided list of 147 approved codes), "priority" (integer 1 through 4 inclusive), "location" (normalized street address in [number, street name, street suffix, unit, city, state, zip] format), "caller_description" (verbatim quote of the caller's description of the problem, maximum 150 characters), "reported_subjects" (array of subject descriptors drawn exclusively from the caller's words), and "narrative" (three to five sentences in past tense, factual, grounded in the call audio).

Each field specification has several layers. The type constraint specifies what kind of data the field accepts. The source constraint specifies where the value must come from: verbatim from the caller, from the CAD code list, from the system, or from officer-supplied information. The fallback specifies what the field should contain if the source material does not support a value: null for optional fields, or a [VERIFY] flag for required fields where the AI could not determine the value. And the validation rule specifies the test a downstream system will run: does the call_type_code appear in the allowed list? Does the priority field contain an integer between 1 and 4? Is the location a parseable street address?

Getting the prompt right requires input from three groups who rarely sit in the same room: the dispatcher or officer who knows what the incident information actually looks like in practice, the IT or systems administrator who knows what the CAD and RMS schemas require, and the supervisor or legal counsel who understands the evidentiary and policy constraints on what each field should and should not contain. Structured-output prompt design is a cross-functional task, not a personal configuration choice.

Constrained Fields and the Code-List Problem

The most common failure mode in AI-to-CAD integration is the unconstrained call-type field. A general-purpose AI tool asked to classify an incident will produce a natural-language description of what the incident appears to be: "domestic disturbance with possible assault," "suspicious vehicle in residential area," "medical emergency involving unresponsive adult." These descriptions are informative. They are not call-type codes. The CAD system does not have an entry for "domestic disturbance with possible assault." It has a code: 240, or DV-A, or DVASS, depending on the system. A dispatcher who tries to push the natural-language description into the call-type field will receive a validation error. A dispatcher who is not paying attention and pushes it into a notes field has created a record where the call-type code field is blank or defaulted, which corrupts statistical reporting, resource-allocation algorithms, and the crime analysis the department uses to set patrol priorities.

The solution is to provide the full code list in the prompt and instruct the AI to select from that list, or to flag the field for human review if no code clearly applies. This works, but it requires the prompt to be updated every time the agency updates its code list, which happens more frequently than most IT teams document. Version drift between the code list in the prompt and the code list in the CAD system is a slow-burning integrity problem that surfaces only when someone checks whether the AI's call-type classifications actually match the agency's current taxonomy.

A more robust design separates the AI from the constrained-field decision entirely. The AI produces the incident narrative and populates unstructured fields. A classification layer, either a rule-based system or a separately trained classifier, maps the narrative to the appropriate code. The classifier is updated when the code list changes. This separation means the large-language model is not responsible for maintaining currency with the agency's evolving code taxonomy, which is a maintenance task the model is not equipped to perform reliably.

Similar code-list problems appear in the RMS context: offense classification codes, disposition codes, UCR (Uniform Crime Reporting, the FBI's national crime statistics framework) codes, NIBRS (National Incident-Based Reporting System, the individual-incident-level successor to UCR) offense codes, and demographic fields that have controlled vocabularies. Each of these is a point where free-form AI output creates a mapping problem that someone has to solve, and if the solution is "the dispatcher decides," the benefit of AI-assisted entry is reduced to the assistance the tool provided for the narrative fields only.

RMS Field Requirements and the Evidence Standard

The RMS schema is more complex than the CAD schema because it carries more categories of information: the offense narrative, the subject's personal information, the evidence inventory, the officer's statement, the case disposition, and in many systems, the body-camera footage links and the digital evidence metadata. Each category has field requirements that interact with legal standards, not just technical ones.

Consider the subject information fields. An RMS record for a charged individual will typically include name, date of birth, address, physical description, identifying numbers, and criminal history flags. Some of those fields are simple string data. Others are constrained by agency policy, state law, and federal guidelines. The race and ethnicity fields, for example, carry specific definitions under FBI reporting standards, and the values the AI produces must align with those definitions, not with whatever descriptors the caller or the officer used informally in their notes. An AI tool that maps a caller's informal description directly to a race code without applying the FBI's controlled vocabulary has produced a record that may be factually accurate but is administratively wrong for reporting purposes.

The narrative fields in the RMS carry the highest evidentiary weight. Unlike the CAD summary, the RMS narrative is likely to be disclosed in discovery, read at deposition, and cited at trial. The structured-output discipline for RMS narrative fields requires the same grounding constraints that the system prompt for general report drafting requires, with the additional structural demand that the narrative fit within the field's character limit, conform to the agency's standard format, and cross-reference the correct case number, report number, and officer information.

The evidence inventory fields introduce a chain-of-custody requirement. When AI assists in documenting evidence items, the structured output must include the item description, the location and time of collection, the collecting officer's identification, and the disposition, whether that is booked into evidence, released at scene, or turned over to another agency. Each of these is a field the AI can populate from the source materials, but each is also a field where a gap-fill error creates a chain-of-custody problem that can result in evidence being suppressed. The structured-output prompt for evidence documentation must include explicit source constraints for each field, and the fallback for any field that cannot be sourced is a [VERIFY] flag, not a plausible guess.

Validation Before the Record

The defining feature of a well-designed AI-to-CAD or AI-to-RMS integration is a validation layer that sits between the AI output and the system of record. This layer does three things: it checks structural validity (is the output valid JSON or the required format?), it checks field constraints (do the values in constrained fields appear in the allowed lists?), and it checks completeness (are all required fields populated, or are there [VERIFY] flags that require human review?). Any output that fails validation goes to a human review queue before it touches the system of record.

Validation before the record is the operational equivalent of the officer's verification pass for report narratives. It is the point at which the machine's output is checked against the standard before it becomes authoritative. Without a validation layer, the AI is writing directly into the record, and the record reflects whatever the AI produced, including its errors.

Building validation is a technical task, but deciding what to validate against is a policy task. The policy questions are: what fields are required and what are optional? What are the allowed values for each constrained field, and who owns the process of keeping that list current? What happens when the AI produces a [VERIFY] flag in a required field: does the record hold in a pending state until a human resolves it, or does the system allow the record to be filed with the flag attached? These are questions for the agency's operations, legal, and IT leadership together, not just the IT team configuring the integration.

The validation layer also creates the audit trail that documents AI involvement in each record. If a record was submitted through the AI-assisted structured-output pipeline, the validation log shows what the AI produced, what the validation found, what flags were raised, how they were resolved, and who resolved them. That log is the documented chain of custody for the AI contribution to the record, and it is exactly the kind of documentation a prosecutor, a defense attorney, or an oversight board will ask for when the record's provenance becomes relevant.

The Officer and Dispatcher Level Practice

From the dispatcher's perspective, working with structured AI output means understanding three things that free-form AI output does not make explicit. First, [VERIFY] flags in required fields are stops, not suggestions. A flag in the priority field means the dispatcher must assign a priority before the CAD entry can be submitted. The AI could not determine it from the available information. The dispatcher owns that determination and the consequences of getting it wrong. In dispatch, a misclassified priority is not a data-quality issue: it is a resource-allocation decision that may cost a life.

Second, the call_type code that the AI populates is a starting point for dispatcher review, not a final determination. Even with a well-constrained code-list prompt, the AI may select a code that is technically defensible but not optimal for how the agency routes calls of that type. The dispatcher who accepts the AI's code classification without review is accepting the AI's routing recommendation, not exercising their own dispatch judgment. The code field is one the AI can help populate; it is not one the AI can finalize without human confirmation.

Third, the structured output created by the AI for a CAD entry is not yet a record. It becomes a record when it is reviewed, corrected, and submitted by the dispatcher. The dispatcher's review and submission are the explicit acts that make the AI output a government record. This mirrors the officer's adoption step for report narratives: the human's review and affirmative action to submit is the point where accountability attaches.

From the officer's perspective, structured output for the RMS requires the same principles applied to more complex field sets. Each field that the AI populates should be verifiable against the source materials. Each field that carries a [VERIFY] flag requires the officer to locate the information in the footage, the notes, or the CAD entry and populate it correctly. The officer who submits an RMS record with unresolved [VERIFY] flags in evidence inventory or subject information fields has created a record with documented gaps that may become chain-of-custody problems later.

The structured-output discipline is most valuable precisely because it makes gaps visible. A narrative drafted without a structured output constraint can be missing information without flagging anything. A structured output with [VERIFY] flags shows exactly where the information is missing, how many fields are affected, and what the record will look like if the officer does not resolve them. Visibility is the prerequisite for accountability. The structured approach does not add work: it reveals the work that was always there and makes sure it gets done before the record is closed.

Key Takeaways

• Structured output means data formatted in a schema with predictable fields, values, and delimiters that a downstream system can validate and ingest. JSON (JavaScript Object Notation) is the most common format for AI-to-CAD and AI-to-RMS integration, though agencies use multiple formats depending on their vendor.
• Prose is not data. A fluent AI narrative that describes an incident accurately cannot be ingested by a CAD or RMS system without human extraction of the required field values. Structured-output prompts replace that extraction step by instructing the AI to populate the schema directly.
• The most common failure mode in AI-to-CAD integration is the unconstrained call-type field, where the AI produces a natural-language incident description rather than the system's call-type code. This requires the full code list to be provided in the prompt, with [VERIFY] flags for cases where no code clearly applies.
• A validation layer between the AI output and the system of record is required: it checks structural validity, field constraints, and completeness, and routes any output with unresolved flags to a human review queue before the record is written.
• Constrained fields in the RMS (offense codes, UCR and NIBRS codes, demographic fields) have controlled vocabularies that must be enforced. AI that maps informal descriptions to constrained fields without applying the required vocabulary produces records that are factually plausible but administratively incorrect for reporting and compliance purposes.
• The dispatcher's submission and the officer's review-and-submission are the explicit acts that convert AI-produced structured output into government records. The human's affirmative action is where accountability attaches, not at the point where the AI produces the output.
• Evidence inventory fields in the RMS carry chain-of-custody requirements. Structured output for evidence documentation must source every field from the materials provided, and the fallback for any field that cannot be sourced is a [VERIFY] flag rather than an inferred value.
• Structured-output prompt design is a cross-functional task requiring input from dispatchers or officers, IT/systems staff who know the schema, and legal or supervisory staff who understand the policy constraints on each field. It is not a personal configuration choice.