The case note was perfect, and it was useless. A caseworker had used the agency's AI tool to draft a contact note from a home visit, and the draft was clean, accurate, and well organized: a paragraph of narrative, a few observations, a clear summary of the safety plan discussed. Then she went to enter it into the state CCWIS (Comprehensive Child Welfare Information System, the case-management system of record), and the system did not want a paragraph. It wanted a contact type from a dropdown, a contact date in a specific format, a location code, a list of participants each linked to a person record, a set of structured safety-assessment fields, and a narrative box with a character limit. The beautiful draft had to be taken apart by hand and retyped, field by field, into the boxes the system would accept. The twenty minutes the AI had saved on drafting, she spent again on transcription. By the end she wondered whether the tool had saved her anything at all. The problem was not the quality of the writing. The problem was the shape of it. The system does not accept prose. It accepts records. This lesson is about making AI produce the record, not the essay.

Why Shape Matters as Much as Content

In human-services work, the place AI output has to land is almost never a blank page. It is a structured system: a CCWIS in child welfare, a commercial platform like Casebook or FAMCare, a state eligibility system for SNAP, TANF, or Medicaid (the federal health-coverage program for low-income people). These systems do not store free text the way a word processor does. They store records made of fields, each with a defined name, type, and set of allowed values. A contact note is not a paragraph; it is a contact type, a date, a method, a set of linked participants, and a bounded narrative. An eligibility determination is not an explanation; it is a program code, a decision value, an effective date, and structured reason fields. If the AI produces a flowing paragraph and the system wants twelve fields, the worker becomes the converter, pulling the paragraph apart and retyping it into boxes.

This is where the genuine time savings of AI documentation either survive or evaporate. The whole premise of AI-assisted documentation, the goldmine of this field, is returning hours to direct work with families. If the AI saves twenty minutes on drafting but costs twenty minutes on reshaping the draft into the system's format, the net gain is zero, and the worker has correctly concluded the tool is not worth the trouble. Structured output is the discipline that protects the time savings. When the AI produces output already shaped to the fields the system expects, the draft drops into the record with verification but without re-transcription, and the saved time stays saved.

Shape also protects something beyond time: data integrity and downstream use. Case-management systems are not just storage. The structured fields feed safety assessments, eligibility logic, court reports, program reporting, and the data that oversight bodies and funders examine. A contact type entered as free text instead of a coded value does not roll up into the unit's contact-frequency reporting. A determination reason typed as a sentence instead of a coded reason does not appear correctly in the program's outcomes data. Getting the shape right is not cosmetic. It is what makes the record function as part of the system rather than as an orphaned block of text sitting in a narrative field.

The system does not accept an essay. It accepts a record. Structured output is the discipline of making the AI produce the record.

Learn the Target Schema First

Before you can ask AI to produce a record in the right shape, you have to know the shape. The target schema is the set of fields the case-management system expects for the specific record you are creating, along with each field's type and its allowed values. Schema here just means the structure: the named fields and the rules about what goes in each. You cannot prompt for a shape you have not defined.

For a child-welfare contact note in a typical CCWIS, the schema might include: contact date (a date), contact type (a coded value from a fixed list such as home visit, office visit, collateral contact, or attempted contact), contact method (in person, phone, video), participants (each linked to an existing person record in the case, not a free-text name), location, purpose, a structured set of safety and well-being indicators, and a narrative field with a character limit. Each of those is a constraint. Contact type must be one of the allowed codes, not a phrase the model invents. Participants must match person records that already exist in the case. The narrative must fit the limit.

For an eligibility determination, the schema is different and the stakes of getting it right are concrete. It might include: program (SNAP, TANF, Medicaid, each a coded value), determination (approved, denied, pending), effective date, benefit amount where applicable, and a reason code drawn from a fixed list of agency-defined determination reasons. A denial reason entered as free prose instead of the correct coded reason can fail to generate the proper due-process notice, the legally required notification that tells the person why they were denied and how to request a fair hearing. The shape of the record is connected to the rights of the person, because the system's structured fields are what trigger the notices and appeal rights the law requires.

The practical step is to extract the schema from the system you actually use, by looking at the data-entry screen, the field list, or the agency's data dictionary, and write it down: field name, type, allowed values, required or optional, any length limit. That written schema becomes the specification you hand to the AI. You are not guessing what the system wants. You are telling the model exactly what to produce, in the system's own terms.

Prompting for the Shape You Need

With the schema in hand, the task becomes telling the AI to produce output in that shape. The principle is direct: describe the structure you want as explicitly as you describe the content, and constrain every field to its allowed values.

A vague prompt produces an essay. "Write a contact note from these visit notes" yields a paragraph, because that is what the words "contact note" most often look like in the model's training data. A structured prompt produces a record. It names each field, states the allowed values for coded fields, and instructs the model to leave a field blank or marked unknown rather than guess. For the contact note, that means something like: produce contact_date, contact_type (one of: home visit, office visit, collateral contact, attempted contact), contact_method (in person, phone, video), participants, purpose, and a narrative under the character limit, and if any field cannot be determined from the source notes, mark it as not stated rather than inventing a value.

That last instruction is the load-bearing one, and it connects structured output to everything taught about hallucination. A model asked to fill a structured field will fill it, and if the source does not contain the value, it will produce a plausible one. Asked for a contact_type when the notes are ambiguous, it may confidently output "home visit" when the contact was actually an attempted visit with no one home. Asked for participants, it may list a parent who was not present because parents are usually present at home visits. The structure does not protect against fabrication; in some ways it invites it, because a field that wants a value pressures the model to supply one. The defense is to instruct the model explicitly to leave unknown fields empty or flagged, and then to verify every field against the source, exactly as you would verify prose. Structured output changes the shape of the verification, from reading a paragraph to checking each field, but it does not remove the need for it.

Constrain Coded Fields to the Allowed List

For any field that must be one of a fixed set of values, give the model the list and tell it to choose only from the list. A contact_type of "wellness visit" is not a valid code if the system's allowed values are home visit, office visit, collateral contact, and attempted contact; it will be rejected on entry or, worse, silently mismapped. Telling the model the exact allowed values, in the system's exact wording, is what keeps the output enterable. When the right value is genuinely unclear from the source, the model should say so rather than pick the closest-sounding code, because a confidently mismatched code is harder to catch than an obviously empty field.

Respect Limits and Required Fields

If the narrative field caps at 4,000 characters, the prompt should set that limit, because a draft that overflows the field gets truncated on entry, often silently, cutting off the end of the narrative where the safety plan or the next-steps language frequently lives. If a field is required, the prompt should treat it as required and flag when the source does not support it, so the worker knows a required value is missing before the system rejects the record or, worse, accepts a guessed one.

Required fields deserve a specific word of caution, because they are where the pressure to fabricate is strongest. A required field cannot be left empty for the record to save, so a worker under time pressure faced with a required field the source does not support is tempted to let the model's guess stand just to get the record filed. That temptation is exactly the moment the not-stated discipline has to hold. The right move when a required field has no support in the source is not to accept a fabricated value but to go back to the source, to the field notes, the prior record, or the person, and get the real value, or to record honestly that the information is not yet available. A required field that the system insists upon does not mean the model is permitted to invent the answer; it means the worker owes the system a true value, and the difference between those two things is the difference between a defensible record and a fabricated one.

It also helps to ask the model to separate what it extracted from what it inferred. A prompt can instruct the model to produce, alongside each field, a brief note of where in the source the value came from, so the worker can confirm the trace quickly. This is not a guarantee, since a model can fabricate its source as readily as its content, but it turns the verification from an open-ended hunt into a guided check: the worker reads the claimed source location and confirms it against the actual notes. For high-stakes coded fields such as a determination or a safety indicator, that guided trace can save real time during verification without lowering the standard.

Formats That Systems Actually Ingest

So far the discussion has been about logical structure: the fields and their values. There is also the question of the physical format the output takes, and the right answer depends entirely on how the output gets into the system.

For the common case, where a worker reads the AI output and types or pastes it into a data-entry screen field by field, the best format is a clearly labeled, human-readable structure: each field name followed by its value, one per line, in the order the entry screen presents them. This is not glamorous, but it is exactly what makes manual entry fast and accurate. The worker reads "Contact type: home visit" and selects home visit from the dropdown; reads "Contact date: 2026-06-18" and enters it; works down the list in order. The output mirrors the screen, so entry becomes transcription of matched fields rather than excavation of values from a paragraph. A worker can verify and enter a field-labeled record several times faster than they can take apart a narrative.

For the case where output is imported programmatically, through an integration, an upload, or an API (an application programming interface, the defined way two software systems exchange data), the system usually expects a machine-readable format such as JSON (JavaScript Object Notation, a structured text format of named fields and values) or a delimited file like CSV. Here the field names and value formats must match the system's expected keys and types exactly. A date the system expects as YYYY-MM-DD will fail if the model emits "June 18, 2026." A field the system keys as "contactType" will not map if the model emits "contact_type." When output feeds an integration, the schema is not a guideline; it is an interface contract, and a mismatch means the record fails to load or loads into the wrong place. This path also raises a privacy obligation, because sending PII (personally identifiable information, the sensitive data that identifies a specific person) through any integration must use only channels the agency has approved for protected data.

A caution that follows from the hallucination lessons: when you ask a model for a strict machine format, it will produce something that looks like that format whether or not the values are right. A JSON object with a perfectly formed structure can contain a fabricated participant or a guessed reason code, and the clean formatting makes the fabrication look more authoritative, not less. The format being valid says nothing about the content being true. Verify the values, not just the syntax.

The Worked Example: From Prose to Record

Return to the caseworker from the opening, with her clean but unusable paragraph, and walk the same visit through the structured approach to see the difference in real terms.

She starts not with "write a contact note" but with the schema she has already extracted from her CCWIS contact screen: contact_date, contact_type (home visit, office visit, collateral contact, attempted contact), contact_method (in person, phone, video), participants (matched to case person records), purpose, safety_indicators (a defined set), and narrative (4,000 character limit). Her prompt gives the model her raw field notes and that schema, and instructs: produce each field in that order with its label; choose coded values only from the allowed lists; do not invent a value for any field the notes do not support, mark it "not stated" instead; keep the narrative under the limit; and use only observations present in the notes.

The output comes back as a labeled record. Contact date matches her notes. Contact type reads "home visit," which she confirms against her notes. Contact method reads "in person," correct. Participants lists the mother and the two children; she checks her notes and confirms the father was not present, and notes the model correctly did not add him. One safety indicator the model marked "not stated" because her notes were silent on it, which is correct and flags for her that she needs to either confirm the observation or leave it genuinely unrecorded rather than letting a guess stand. The narrative fits the field. She reads each value against her source, corrects one purpose-field wording, and enters the record field by field, top to bottom, matching labels to boxes.

The verification is real work and she does not skip it, because a structured record can be fabricated as easily as a paragraph. But she is checking fields against a source, not rebuilding a record out of prose, and she is entering matched labels rather than excavating values. The twenty minutes the AI saved on drafting stay saved, because the output arrived in the shape the system accepts. That is the entire point of structured output: it is what carries the AI's time savings across the gap between a good draft and a usable record, without sacrificing the verification the work demands.

Key Takeaways

• Case-management systems (a CCWIS, Casebook, FAMCare, a state eligibility system) store structured records made of defined fields, not free prose. AI output that arrives as a paragraph must be reshaped into fields by hand, which erases the time the AI saved on drafting.
• Structured output is the discipline of making AI produce the record in the shape the system accepts, so the draft drops in with verification but without re-transcription, protecting the time savings that are the whole point of AI-assisted documentation.
• The shape is not cosmetic: structured fields feed safety assessments, eligibility logic, reporting, and the due-process notices that the law requires, so a wrong or free-text value can break downstream functions and even fail to generate a required denial notice.
• Learn the target schema first: extract the field names, types, allowed values, required flags, and length limits from the actual system, and use that written schema as the specification you hand the AI.
• Prompt for the shape as explicitly as for the content: name every field, give coded fields their exact allowed values, set length limits, and instruct the model to mark unknown fields as not stated rather than inventing a value.
• Structured output does not remove the hallucination risk; a field that wants a value pressures the model to supply one, and a clean format can make a fabricated value look authoritative. Verify every field against the source, the same standard as for prose.
• Match the physical format to the entry path: a labeled, screen-ordered layout for manual entry, and an exact machine format (JSON or CSV with the system's exact keys and value formats) for integrations, where the schema becomes an interface contract and PII must travel only on approved channels.
• Done right, structured output is what carries AI's time savings across the gap between a good draft and a usable record, returning hours to families without sacrificing accuracy or verification.