It was 6:40 in the evening, and the caseworker still had three case notes to write before she could go home. She had carried a caseload of 28 families that month, and the home visit she was about to document had happened nine hours and four other visits ago. She opened the agency's AI documentation tool, pasted in the handful of phrases she had thumbed into her phone during the visit, and typed a single instruction: "Write up my home visit note for the Alvarez family." The draft came back in ninety seconds, and it was beautiful. It was three clean paragraphs in the exact register of a professional case note. It described a tidy kitchen, two children who "appeared well-adjusted and engaged," a mother who "presented as cooperative and forthcoming," and a follow-up plan. The trouble was that the caseworker had written none of that. Her phone notes said "kitchen ok, 2 kids home, mom tired, asked re: childcare voucher." The model had not summarized her visit. It had imagined a plausible one. The difference between those two things is the entire subject of this lesson, and learning to control it is the difference between an AI tool that returns hours to your week and one that quietly seeds your case records with fiction.

Why the Default Output Drifts From the Record

To get accurate output, you first have to understand why inaccurate output is the default. A large language model (LLM, the kind of AI system that generates text from a prompt) does not work the way a transcription service works. A transcription service has only one job: reproduce what was said. An LLM has a different job by design: produce fluent, plausible text that continues from the prompt it was given. When you hand it four fragmentary phrases and ask for a full case note, you are asking it to bridge an enormous gap between what you gave it and what a finished note looks like. It bridges that gap the only way it can: by predicting the words that statistically tend to appear in case notes like this one, drawn from the millions of documents it was trained on.

That is the mechanism behind the Alvarez draft. The model had seen countless home-visit notes in its training data. It knew that such notes describe the home, the children, and the parent's demeanor, and that they usually end with a follow-up plan. So when your input was thin, it did not stop and say "I do not have enough information." It produced the note that a worker like you, in a situation like this, typically writes. The phrase "appeared well-adjusted and engaged" was not extracted from your observations. It was generated because it is the kind of phrase that fills that slot in that kind of document.

This matters in this field more than almost any other, because a case note is not a draft email or a marketing blurb. It is a legal record. It travels to the next court review, the next safety assessment, the next worker who opens the file. An invented detail about a child or a parent, stated in the confident, professional tone the model uses for everything, carries the evidentiary weight of your professional observation, a weight it does not deserve because it never happened. The half-day you spend documenting is exactly the burden AI can ease, but only if the output is grounded in what you actually saw rather than in what the model guessed you probably saw.

The model's default job is to produce plausible text, not accurate text. Accuracy is something you have to demand and then verify; it is never the free gift in the box.

The Grounding Instruction: Forcing the Model to the Record

The single most important technique for accurate case documentation is also the simplest to state and the hardest to remember at 6:40 PM: give the model the actual record, and instruct it explicitly to use only what is in that record. This is called grounding. You are anchoring the model to a specific source rather than letting it draw on the vast ocean of plausible text in its training data.

Compare the Alvarez prompt to a grounded one. The first prompt, "Write up my home visit note for the Alvarez family," gives the model almost nothing to ground on, so it invents. A grounded prompt looks different. It supplies the raw field notes in full. It states the source boundary in plain words: "Using only the field notes below, draft a home-visit note. Do not add any observation, detail, or conclusion that is not present in these notes. If something a case note would normally include is missing from my notes, leave it out and mark it as 'not documented' rather than filling it in." Then it pastes the notes. That instruction does two things at once. It tells the model where the facts come from, and it tells the model what to do when the facts run out, which is the exact moment the default behavior would otherwise invent.

Consider the time math, because it is the whole reason you are doing this. A worker who pastes thin notes and accepts a beautiful invented draft spends perhaps three minutes producing a note that is unsafe and may take far longer to repair, or may cause a harm that no amount of time can repair. A worker who writes specific field notes during the visit, takes ninety seconds to paste them with a grounding instruction, and then spends four minutes verifying the result has produced a trustworthy note in under ten minutes that used to take twenty-five. The grounding instruction is not bureaucratic overhead. It is the move that makes the time savings real instead of illusory.

Good Field Notes Come First

Grounding can only anchor the model to what you give it. If your field notes from the visit are four words, the model has four words of truth and a large gap to fill, and grounding cannot manufacture detail that was never captured. This is the uncomfortable foundation of accurate AI documentation: it starts before you ever open the tool, in the specificity of the notes you take during or immediately after the contact.

This does not mean writing the full note in the field; that would defeat the purpose. It means capturing the specific, verifiable observations that the polished note will be built from. "Kitchen ok" is too thin to ground on. "Kitchen clean, food in fridge, working stove, no safety hazards observed" is a set of real observations the model can faithfully render and you can later verify. The discipline is to capture facts, not impressions, and to capture enough of them that any sentence in the AI draft can be traced back to something you actually wrote. A useful test: if a sentence in the AI draft cannot be matched to a phrase in your field notes, it is a candidate for deletion, not a detail to be trusted.

Constrain the Model to Observation, Not Inference

The next technique attacks the most dangerous habit a model has in this field: the slide from observation to inference. A case note is supposed to record what was observed. The model, trained on prose that freely mixes observation with interpretation, will happily write "the mother was anxious about the upcoming hearing" when what you actually observed was that she asked three times when the hearing was. The first is an inference about an internal state. The second is an observed behavior. In casework, the distinction is not pedantic. A note that records inferences as if they were observations can mislead a court, color the next worker's view of a parent, and prejudice a family who never had a chance to contest a characterization that was never theirs.

You control this in the prompt. A strong instruction reads: "Record only observed behaviors and statements. Do not describe internal states, emotions, motives, or conclusions unless I have explicitly documented them. If my notes say a parent 'asked repeatedly about the hearing date,' write that, not that the parent 'was anxious.' Attribute every statement to its source, for example 'mother reported' or 'child stated,' rather than asserting it as established fact." This forces the model into the posture of a careful caseworker who knows the difference between what they saw and what they think it means.

Here is the technique applied. Your field notes for an intake contact read: "Mom said dad moved out 2 wks ago. Kids quiet during visit. Younger child stayed close to mom. No food visible in kitchen, mom said she gets paid Friday." A model left to its own devices might produce: "The home showed signs of instability and food insecurity, and the children appeared withdrawn and fearful, likely due to the recent separation." Every clause there is an inference dressed as an observation. The grounded, constrained version reads: "Mother reported the father moved out approximately two weeks ago. The children were quiet during the visit, and the younger child stayed close to the mother. No food was visible in the kitchen; the mother reported she is paid on Friday." The second version is shorter, it is true to the record, and it is defensible if an attorney reads it aloud in a hearing. The first version is a due-process problem waiting to surface.

"Anxious," "withdrawn," "unstable," and "fearful" are conclusions. "Asked three times," "stayed close to the parent," and "no food visible" are observations. Make the model write the second kind and refuse the first.

Make the Model Flag Gaps Instead of Filling Them

The Alvarez draft failed at a specific point: the moment the model ran out of real input and kept writing anyway. The most powerful accuracy technique after grounding is to redirect that moment. Instead of letting the model fill a gap with plausible fiction, instruct it to surface the gap so you can fill it with fact.

The instruction is a single added sentence: "Where my notes do not contain information that this type of document normally includes, do not invent it. Insert a clearly marked placeholder such as '[NOT DOCUMENTED: follow-up plan]' so I can complete it from my own knowledge." This converts the model's most dangerous behavior into its most useful one. A draft that comes back with three bracketed placeholders is not a failure of the tool. It is the tool telling you exactly where your note is incomplete, which is information you need and would otherwise have to find by reading the whole draft suspiciously. The placeholders become your checklist.

Think about what this does to the verification burden. Without it, every sentence in the draft is a suspect, because any of them could be invented and they all look the same. With gap-flagging, the model has separated the draft into two zones: the prose it built from your notes, and the bracketed spots it could not fill. Your attention goes first to the brackets, which you complete from your own knowledge, and then to verifying the grounded prose against your notes. You have turned an undifferentiated wall of confident text into a structured object with the uncertainty marked. For a worker documenting five visits at the end of a long day, that structure is the difference between catching the gaps and filing over them.

Ask the Model to Show Its Source

A complementary technique is to require the model to tie each statement to the part of your input it came from. The instruction: "After the draft, provide a short table that lists each factual claim in the note and the exact phrase from my field notes that supports it. If a claim has no supporting phrase, mark it 'UNSUPPORTED.'" This is not a perfect safeguard, because a model can sometimes generate a plausible-looking source mapping that is itself unreliable, but it changes the economics of verification in your favor. Most invented claims will land in the UNSUPPORTED column because there genuinely is no source phrase, and the ones that try to fake a source are easier to catch because you can check the cited phrase against your actual notes in seconds. The technique surfaces the model's reach beyond the record and points your verification straight at it.

Iterate Toward Accuracy Without Reintroducing Drift

The first grounded draft will rarely be perfect, and the way you revise it can either preserve accuracy or quietly destroy it. The risk in iteration is that a loose follow-up reopens the door to invention. "Make it sound more thorough" is exactly the kind of instruction that invites the model to add plausible detail, because "more thorough" reads to the model as "add the content a thorough note would have," and it has no way to know that content has to be true.

Accurate iteration keeps every revision inside the source boundary. Instead of "make it more thorough," say "reorganize the note so the safety observations come first, but add no new content and remove nothing that is supported by my notes." Instead of "expand the section on the children," say "I have additional field notes about the children; here they are; integrate only these and nothing else." Each revision instruction should either restructure what is already grounded or introduce a new, explicitly provided source. The moment a revision instruction asks the model to generate rather than to reorganize or incorporate, you are back in Alvarez territory.

A short worked sequence shows the discipline. A worker grounds the model on field notes and gets a clean draft, but the draft buries a safety-relevant observation (an unsecured medication bottle) in the third paragraph. The unsafe fix is "rewrite this to emphasize safety concerns," which invites the model to elaborate. The safe fix is "move the sentence about the medication bottle to the top of the note as the lead safety observation, and change nothing else." The note now reads correctly for a supervisor scanning for safety, and not one new fact entered the record. Across a week of documentation, this habit, restructure and incorporate but never invent, is what lets a worker trust the tool enough to actually use it.

Verify, Because Grounding Reduces Risk but Does Not Remove It

Every technique in this lesson reduces the rate at which a model strays from the record. None of them eliminate it. A grounded, constrained, gap-flagged prompt can still produce a draft that subtly misstates a date, attributes a statement to the wrong family member, or carries a small invented clause through the cracks. This is why the techniques here are the front half of a two-part discipline, and verification is the back half that is never optional. The grounding work makes verification fast and targeted; it does not replace it.

Verification of a grounded draft is a claim-by-claim comparison against the source, and the grounding techniques have made it efficient. You check the bracketed placeholders first and complete them. You check the source table, if you requested one, and resolve every UNSUPPORTED entry by either deleting the claim or correcting it from your notes. Then you read the grounded prose against your field notes, confirming that each observation in the draft traces to something you actually wrote. A claim that cannot be traced is removed, not retained because it seems plausible; plausibility is precisely the property that invented content has. This is the same standard a court would expect, because the note may end up in front of one.

The accountability point is worth stating plainly, because it is what makes the verification non-negotiable. The note carries your name and your professional signature. If it contains a false statement, the fact that an AI tool drafted it does not transfer the responsibility to the vendor or the model. "The AI wrote it" is not a defense in a fair hearing, a licensing review, or an agency investigation. The worker who files the document is accountable for every claim in it. The grounding techniques are how you make that accountability sustainable under a real caseload: they shrink the verification job from "treat the whole draft as suspect" to "check the flagged gaps and confirm the traced claims," which is a job you can actually finish before you go home.

Key Takeaways

• An LLM's default behavior is to produce plausible text, not accurate text. When you give it thin input and ask for a full case note, it fills the gap with statistically likely prose drawn from its training data, not from your visit. Accuracy must be demanded and verified; it is never the default.
• Grounding is the core technique: supply the actual field notes and instruct the model in plain words to use only what is in them, adding nothing and leaving out what is missing. Grounding anchors the model to the record instead of the ocean of plausible text it was trained on.
• Accurate AI documentation starts before the tool, with specific field notes. "Kitchen clean, food in fridge, working stove" can be grounded and verified; "kitchen ok" cannot. If a sentence in the draft cannot be traced to a phrase in your notes, it is a candidate for deletion.
• Constrain the model to observed behaviors and statements, not inferences about internal states. "Asked three times about the hearing" is an observation; "was anxious" is a conclusion that can mislead a court and prejudice a family. Force the model to write the first and refuse the second.
• Make the model flag gaps with clear placeholders such as "[NOT DOCUMENTED]" rather than filling them with invention. This turns the model's most dangerous behavior, writing past the end of the facts, into a structured checklist of exactly where your note is incomplete.
• Iterate without reintroducing drift. Revision instructions should restructure grounded content or incorporate explicitly provided new notes, never ask the model to "make it more thorough," which invites it to add plausible but unverified detail.
• Grounding reduces the rate of fabrication but never removes it. Verification against the source remains mandatory: check placeholders, resolve unsupported claims, and trace every observation in the draft to your field notes before filing.
• The note carries your name. "The AI wrote it" is not a defense in a fair hearing, a licensing review, or an agency investigation. The grounding techniques exist to make that accountability sustainable under a real caseload by making verification fast and targeted.