โ†
AI for Social Work & Human Services
Proficient ยท M11 ยท lesson 11 of 18 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Mapping a Case Process for AI Integration
๐Ÿ“–
now learning

Mapping a Case Process for AI Integration

15 min

The unit supervisor had a whiteboard, a stack of dry-erase markers, and seven caseworkers who were already using an AI documentation tool in seven different ways. One worker fed it her raw home-visit notes and trusted the draft almost entirely. Another used it only to clean up grammar. A third had quietly started asking it whether a family "seemed high risk," which was the use that made the supervisor's stomach drop. There was no map. Each worker had drawn their own private line between what the AI did and what they did, and those lines were inconsistent, undocumented, and in one case dangerously far over into territory where a model should never go. So the supervisor did the thing this entire lesson is about. She drew the actual case process on the whiteboard, step by step, from the moment a report comes in to the moment a judge rules, and then she walked the unit through every single step and asked one question at each: is this a step a machine can help with, or is this a step a human being must own? By the end of the afternoon the unit had something it had never had before: a shared, written map of where AI belongs in their work and, just as important, where it must never be.

Why You Map Before You Automate

Most AI failures in human services do not happen because a tool was bad. They happen because nobody decided, in advance and in writing, exactly which steps of the work the tool was allowed to touch. A caseworker under deadline pressure, handed a capable model and no map, will let the tool drift into whatever step it seems to handle well. The model is fluent and confident at every step, including the ones where its involvement is a due-process violation waiting to happen. Fluency is not a signal of appropriateness. The model will just as smoothly help draft a note (appropriate, with verification) as it will offer a risk verdict on a family (never appropriate as a verdict). Without a map, the worker has no way to tell those apart in the moment, because both come back looking equally polished.

Mapping is the discipline of making the boundary explicit before the tool is in anyone's hands. You take a real case process, break it into its actual steps, and label each step as one of three kinds: a step where AI can do meaningful work under human verification, a step where AI can assist in a narrow supporting role, and a step that is human-only and must stay that way no matter how capable the tool becomes. The product is a marked-up process map. It is the foundation for every workflow the rest of this level builds, because you cannot design a caseworker-AI handoff or ground a model on the record until you have decided where in the process the handoff happens and which steps the grounding serves.

This sits directly on the cardinal rule of the field: AI informs, humans decide. The decisions in this work, to remove a child, to substantiate a report, to deny benefits, are among the most consequential any government makes, bound by due process and equity, and an algorithm must never make them. "The model said so" is never a sufficient reason for a consequential decision. The map is how that principle stops being a slogan on a poster and becomes an enforced property of the actual workflow, step by labeled step.

A model is fluent at every step of the work, including the steps where it must never act. Fluency is not permission. The map is where you decide permission in advance, in writing, before the deadline makes the decision for you.

Breaking the Process Into Real Steps

The first move is to write down the actual process, not an idealized version of it. Take a CPS (child protective services) investigation as the worked example, because it contains the full range of step types in one process. Resist the urge to map it at a high level with four big boxes. Map it the way it actually runs, because the AI-ready steps and the human-only steps hide inside the big boxes, and a coarse map cannot tell them apart.

A realistic decomposition of a CPS investigation might run like this. A report is received at the hotline and screened for whether it meets the statutory threshold for investigation. If screened in, it is assigned to a worker with a response-time clock attached, often 24 to 72 hours depending on the alleged severity. The worker reviews the case history in the CCWIS (Comprehensive Child Welfare Information System, the state's child-welfare case-management system) and any prior reports. The worker conducts the initial home visit and interviews the child, the parents, and collateral contacts. The worker documents each contact in a case note. The worker completes a structured safety assessment. The worker reaches a safety decision: can the child remain safely in the home, with or without a safety plan. If the case proceeds, the worker drafts a court report, the report is reviewed by a supervisor, and the matter goes before a judge who makes the legal findings. Each of those is a step, and several of them contain sub-steps that deserve their own line.

Notice what this decomposition reveals. The single phrase "do the investigation" hides at least a dozen distinct steps, and they are not all the same kind. Reviewing prior case history and summarizing it is a different kind of task than deciding whether a child is safe. Documenting a contact is a different kind of task than interviewing the child. A coarse map that says "investigation" as one box would force a single AI policy onto tasks that need opposite policies. The granularity is the point. You map at the level where each step can be honestly labeled.

The Three Labels: AI-Ready, AI-Assist, Human-Only

With the steps written down, you label each one. Three labels do the work, and the discipline is in applying them honestly rather than optimistically.

AI-Ready (under verification)

An AI-ready step is one where the model can do meaningful work and a human verifies the output before it counts. These are overwhelmingly the documentation and summarization steps, the goldmine of the field. Drafting a case note from the worker's field notes is AI-ready. Summarizing six months of prior case history in the CCWIS into a background section is AI-ready. Drafting the narrative portions of a court report from the worker's inputs is AI-ready. Producing a first-draft summary of an intake packet is AI-ready. In every one of these, the model returns hours to the worker, and a human verification step, the claim-by-claim trace to the source record, stands between the draft and the case file. AI-ready does not mean AI-unsupervised. It means the model produces and the human verifies, and the verification is a non-negotiable part of the step, not an optional follow-up.

AI-Assist (narrow supporting role)

An AI-assist step is one where the model plays a limited, clearly bounded supporting role inside a step that a human is still firmly driving. The line between AI-ready and AI-assist is one of scope: in AI-ready the model produces a substantial draft; in AI-assist it does something smaller and more contained. Using the model to reorganize the worker's own written observations into the agency's required note format is AI-assist. Using it to flag that a drafted report is missing a required section is AI-assist. Using it to surface the questions a thorough worker would ask before a particular kind of visit is AI-assist, because the worker still decides which to ask and owns the interview. The defining test for AI-assist is that the model touches the form of the work, not its substance, and the human remains the author of every judgment.

Human-Only (the bright line)

A human-only step is one where the consequential judgment of the work lives, and no degree of model capability changes its label. The safety decision is human-only: whether a child can remain safely in the home is a determination a caseworker and supervisor make and a court reviews, never a model. The substantiation decision is human-only. The eligibility determination that approves or denies a benefit is human-only. The interview of a child or a parent is human-only, because it is a human relationship and a due-process event, not a data-collection task. The legal findings are human-only by law. These steps are the reason the whole map exists. Labeling them is not a technical exercise; it is the act of drawing the bright line that protects the people in the system, and writing it down so a worker under pressure cannot quietly erase it.

The supervisor's stomach dropped earlier in this lesson for a precise reason: the worker asking the model whether a family "seemed high risk" had taken a human-only step, the safety judgment, and handed it to a tool. That is the exact drift mapping prevents. A risk signal can be an audited input under mandatory human review, which is the careful subject of the next chapter, but a risk verdict is a human-only decision, and the difference between an input and a verdict is the difference between a labeled AI-assist step and an erased bright line.

The Test Questions for Each Step

Labeling cannot be done by feel, because feel will follow convenience under deadline pressure. It is done by asking the same set of questions at every step, the way the supervisor went around the whiteboard. Four questions decide the label.

Does this step produce a consequential decision about a person? If the step decides whether a child is removed, a report is substantiated, or a benefit is granted or denied, it is human-only. This question alone resolves the highest-stakes steps, and it resolves them the same way every time regardless of how good the tool is. A consequential decision about a person is human-only because due process and the cardinal rule require it, not because the model is not smart enough.

Does the output of this step become a legal record? If yes, and the step is not itself a consequential decision, it is a candidate for AI-ready, but only with verification, because the output will be read by a court and an advocate and must meet a court-record standard. Case notes and court reports live here. The legal-record consequence is exactly why the verification step is welded to the AI-ready label and cannot be detached from it.

Is this step a human relationship or a due-process event? An interview, a family meeting, the delivery of a removal decision, the explanation of a benefit denial and the right to a fair hearing: these are human-only not because a machine could not generate words but because the step is an encounter between the agency and a person with rights, and the humanity and accountability of the encounter are the substance of the step, not a wrapper around it.

If this step were done wrong by the model and not caught, who is harmed and how badly? This is the question that calibrates the verification intensity of the AI-ready and AI-assist steps. A formatting error in a note is low harm. A fabricated observation in a court report can contribute to a wrongful removal. The harm-if-uncaught answer tells you how heavy the human check on a step must be, and it sometimes reveals that a step you were tempted to call AI-ready should be AI-assist or carry an unusually rigorous verification gate.

Run a real step through these. "Summarize the family's prior CPS history from the CCWIS into the background section of the court report." Consequential decision about a person? No, it is a summary. Becomes a legal record? Yes, it goes in the court report. Human relationship or due-process event? No. Harm if wrong and uncaught? High, because a fabricated prior incident can shape how a judge sees the family. Label: AI-ready, with a rigorous verification gate, specifically a trace of every historical claim to a CCWIS entry. The questions did not just produce a label; they produced the label and the strength of the check that has to come with it.

The Same Method on a Benefits Process

The four questions are not specific to child welfare; they sort any human-services process the same way. Take a SNAP (Supplemental Nutrition Assistance Program, the federal food-assistance benefit known as food stamps) eligibility process and run its steps through the same labeling. An application is received and logged. The worker gathers and verifies documentation: income, household composition, expenses. The worker enters the data and the system or worker applies the eligibility rules. A determination is reached to approve or deny, at a specific benefit amount. A notice is generated and sent to the applicant, including the right to a fair hearing. If the applicant requests a hearing, the agency prepares for and participates in it.

Label them with the questions. Logging and organizing an application packet: no consequential decision, not a legal-record judgment, not a human encounter, low harm if a formatting summary is wrong and caught. AI-ready or AI-assist. Drafting a plain-language summary of a complex application for the worker to review: AI-ready under verification. The eligibility determination itself, approve or deny at what amount: this is a consequential decision about a person that decides whether a family eats, so it is human-only, with AI permitted only to surface the relevant rule for the worker to apply and verify, never to issue the determination. Generating the determination notice: AI-ready as a drafting step, but with verification that the stated reason and the fair-hearing language are correct, because the notice is the document that triggers the applicant's due-process rights. Explaining the denial to the applicant and their right to challenge it: human-only, a due-process encounter. The map of a benefits process has the same skeleton as the CPS map: AI clusters on the documentation and drafting, the determination and the human encounter stay human-only, and the notice that carries due-process rights gets a drafting label welded to a verification gate.

One subtlety the benefits process exposes sharply: a wrong eligibility denial harms someone immediately and may never be corrected, because the applicant may lack the knowledge, language access, or time to request a fair hearing. That harm-if-uncaught answer is why the determination is not merely human-reviewed but human-made, and why even the AI-ready notice step carries a verification gate on the policy reason. The same four questions, applied honestly, protect the family at the exact step where an automated shortcut would have hurt them.

Reading the Finished Map and Designing the Handoffs

A completed map of the CPS investigation, labeled honestly, has a shape worth seeing. The documentation and summarization steps light up as AI-ready: history review and summary, contact-note drafting, court-report narrative drafting, intake summarization. A few steps come out AI-assist: format conversion, completeness checks, pre-visit question prompts. And a clear set of steps stand as human-only and immovable: the interviews, the safety assessment judgment, the safety decision, the substantiation decision, any eligibility determination in a benefits process, and the legal findings. The map shows at a glance that AI clusters on the documentation burden, which is where it returns the most time and carries the least risk, and that it is held off the consequential decisions, which is where the cardinal rule lives.

The most important features of the map are the transitions between an AI-touched step and a human-only step, because those are the handoffs where judgment changes hands and where things go wrong if the boundary is fuzzy. The transition from "AI drafts the court-report narrative" (AI-ready) to "worker and supervisor decide whether the case proceeds and what to recommend" (human-only) is a handoff that must be explicit: the AI-produced draft is an input the humans verify and then reason from, never a recommendation they ratify. The transition from "AI summarizes prior history" to "worker forms a judgment about the family" is a handoff where the worker must remember that the summary is a verified convenience, not a conclusion. Marking these handoffs on the map is what the next lesson, on designing the caseworker-AI handoff, builds on directly, and grounding the AI on the case record, the lesson after that, is what makes the AI-ready steps trustworthy enough to verify quickly. The map is the prerequisite for both.

Designing a handoff well means deciding three things at each transition and writing them on the map. First, what exactly crosses the boundary: a verified draft, a summary, a list of surfaced questions, never an unverified output and never a recommendation. Second, what the human must do before relying on what crossed: for an AI-ready draft entering a human-only decision step, the human must complete the verification trace first, so an unverified draft can never reach a decision. Third, what gets recorded at the handoff: that the AI produced a draft, that a named human verified it, and that the human, not the model, made the decision that followed. Those three decisions turn a fuzzy transition into a controlled one, and they are what an audit trail is later built from.

A worked handoff makes this concrete. At the transition from "AI drafts the court-report narrative" to "supervisor reviews and the team decides whether to recommend continued court involvement," the map should specify that what crosses is the worker's verified draft, not the raw AI output; that the worker has already traced every observation to field notes and every history claim to a CCWIS entry before the supervisor sees it; and that the record shows the draft was AI-assisted, was verified by the worker, and that the recommendation to the court was the professional judgment of the worker and supervisor. If a worker tried to pass the raw AI draft straight into the decision step, the map would show that step was skipped, which is exactly the failure the handoff design exists to make visible. The handoff is not a moment of trust; it is a checkpoint with a required action and a record.

One more property makes a map useful rather than decorative: it is written, shared, and governed. The supervisor's whiteboard became a one-page document that every worker in the unit had, that new workers were trained on, and that the unit revisited when the tool changed or a new use case appeared. A map that lives in one worker's head is the same as no map, because the drift it prevents happens precisely when an individual worker is tired and alone with a deadline. A written, shared map is also what an agency shows an oversight reviewer, an advocate, or a court to demonstrate that the boundary between AI assistance and human decision is deliberate, documented, and enforced, which is the difference between a defensible AI practice and a collection of private habits.

Key Takeaways

  • Most AI failures in human services come not from a bad tool but from no decision, in advance and in writing, about which steps of the work the tool may touch. Mapping makes the boundary explicit before the tool is in anyone's hands.
  • A model is fluent and confident at every step, including the steps where its involvement is a due-process violation. Fluency is not a signal of appropriateness, so the appropriate role for AI at each step must be decided by mapping, not by what the tool seems to handle well in the moment.
  • Map the real process at a fine grain. A coarse map (one "investigation" box) hides AI-ready and human-only steps inside the same box and forces a single policy onto tasks that need opposite policies.
  • Label every step AI-ready (the model produces, a human verifies, common for documentation and summarization), AI-assist (a narrow supporting role touching the form not the substance), or human-only (the consequential judgments and due-process events, immovable regardless of tool capability).
  • Four test questions decide each label: Does the step produce a consequential decision about a person? Does its output become a legal record? Is it a human relationship or due-process event? If the model did it wrong and it was not caught, who is harmed and how badly? The last question also sets how heavy the verification on an AI-ready step must be.
  • The consequential decisions (remove a child, substantiate a report, decide eligibility) and the human encounters (interviews, delivering a decision, explaining the right to a fair hearing) are always human-only. A risk signal can later be an audited input under mandatory human review, but a risk verdict is a human-only decision, and erasing that line is the exact drift mapping prevents.
  • The handoffs between AI-touched steps and human-only steps are where judgment changes hands and where fuzzy boundaries cause harm; marking them explicitly is the foundation for designing the caseworker-AI handoff and for grounding the AI on the case record.
  • A map only works if it is written, shared, trained on, governed, and revisited. A map in one worker's head prevents no drift, because drift happens when a tired worker is alone with a deadline. A written map is also what makes the AI practice defensible to a court, an advocate, and an oversight reviewer.