Key Guidance for a Legal Help Q&A Bot
Many teams want a legal help Q&A bot, the task with the most demand and the most risk. This is a note rather than a build manual: it flags the handful of things that most decide whether a bot is safe and useful, and it points to the grounding, measurement, and toolkit guides for the depth. It is also honest about what a bot still cannot do.
Common Legal Help AI. Working draft for comment. Margaret Hagan, Stanford Legal Design Lab.
Brief advice is the task people most want from a legal help bot, and it is the one most likely to hurt them when it goes wrong. A confident wrong answer about a filing deadline or an eviction defense is worse than no answer at all, because the person acts on it. The cohort spent most of its evaluation effort on this task, and the findings point to a few things worth getting right before anyone builds. This note flags them, with pointers to the guides that carry the detail.
Build the parts that outlast the model
The model you call this year is the replaceable layer, and a better or cheaper one will arrive within months. What endures is the verified content the bot answers from, the grounding layer that feeds that content to the model, the safety wrapper that catches the dangerous questions, and the evaluation that tells you whether any of it works. A team that puts its effort into those four can swap the underlying model as a configuration change rather than a rebuild. A team that pours its effort into prompt-tuning one model has to start over when the model changes.
Ground every answer in content you have verified
The clearest finding from the evidence guide is that grounding a model in a verified list of your own resources lifted the quality of its answers across every model tested. So the first build decision is the grounding architecture. Assemble the verified content for the issues your bot will cover, tag each piece with its LIST issue code and its jurisdiction, retrieve the relevant passages at answer time, and require the bot to cite the source it used.
Two details from the testing shape how you do this. Quality and fit beat raw volume, because a small, well-structured set of content outperformed a much larger, loosely relevant one, so you curate rather than dump everything in. And loading a long article into the prompt helped when the article fit the question and could hurt a strong model when it did not, so you retrieve the passage that matches the question rather than the whole document.
Choose how you will build the retrieval
You do not have to write a retrieval stack from scratch, and there are two paths depending on how much engineering you have. If your content lives in a content management system, that system may already offer modules that build the vector index for you and keep it in sync as content changes, which is the low-code path: one cohort team, Ohio Legal Help, runs this on Drupal using its AI and Search API AI modules against a managed vector database. If you need more control, or your content comes from many sources, a framework like LangChain gives you document loaders, chunking, and retrievers in code, at the cost of more technical expertise. Either way, the payoff over keyword search is semantic search: a person who types "I was kicked out of my place" gets the eviction article even though they used none of the words a keyword index needs.
Know what retrieval is good for. It fits articles that explain a focused topic. It fits poorly for hierarchical triage taxonomies and for forms, which branch and depend on the person's answers, and which an agent that walks the tree and asks as it goes will serve better than passages pulled from a vector store.
Get the retrieval right, not just present
A few patterns separate a system that demos well from one that holds up. Search small, precise chunks, but hand the model the larger section they came from, so it answers with full context rather than a ripped-out paragraph. Retrieve broadly and then re-rank hard: pull many candidates and narrow to the few worth reading. Rewrite the user's query before you search when their phrasing is messy. And filter by metadata, the jurisdiction and the issue, before retrieval, so the system is choosing among the right content in the first place.
Constrain what the model is allowed to output
The strongest defense against a confident wrong detail is to not let the model invent it. Use structured outputs. When the bot cites, require the links to come from the content's metadata rather than being generated, which is the single most effective guard against fabricated citations. When the bot classifies a person's issue, require it to choose from your existing taxonomy values rather than writing its own, so the result maps exactly onto a real category. This is the same principle as the citation verifier: the model proposes, and a deterministic rule decides what is allowed through.
Decide what a good answer is before you build one
The measurement guide lays out an eight-dimension rubric, and the discipline here is to set your target on each dimension before you write a line of code. The dimensions are legal accuracy, completeness, jurisdiction precision, safety as a veto that can fail an otherwise strong answer, tone, actionability, personalization, and the dimensions specific to your issue area. Writing these targets down turns "the answer seems fine" into something you can measure and hold the bot to, and it gives you the rubric you will score against later.
Wrap the dangerous questions so they get caught
The hardest finding from the testing is that strong models sometimes gave their most confident answers on the highest-risk questions, which is the most dangerous failure a legal bot can have. The response is a safety wrapper that works at the level of the scenario rather than the individual answer. For each high-risk situation, the wrapper carries the risk tier, the clarifying questions the situation demands, and the trigger for handing off to a human. The cohort's 150 Priority Issues are a starting set of these scenarios. The practical move is to identify your own high-risk scenarios first, meaning anything with a deadline, a safety stake, or an irreversible consequence, and to write the clarifying and escalation rules for those before the bot ever takes a public question.
Make it ask instead of guess
The user a bot is most likely to fail is the person in an emergency who leaves out the detail that changes the answer. A good legal bot asks a clarifying question when the jurisdiction, the deadline trigger, or the person's situation is unclear, and it produces an answer only once it has what it needs. Build the clarifying turn into the conversation flow, and treat a missing jurisdiction as something to ask about rather than something to assume, because an answer that is correct for the wrong county is still a wrong answer.
The reliable way to do this is to write down, for each issue, the key information questions a careful advisor would always ask: the handful of variables that change the answer, like the type of rental agreement or whether the person has been served. Treat that list as fixed for the issue, and have the bot work through it before it answers. These are the same key variables the safety wrapper carries, so writing them once serves both. A useful prompt-engineering move is to let the model first reason privately about what the person left out, then ask for it directly in plain language, rather than deciding on its own to answer without it.
Evaluate it honestly, with more than a model's opinion
The most useful evaluation finding, replicated across rounds, is that a model asked to judge answers passed almost everything, while the deterministic checks carried the real signal. So you evaluate with both. Run a model judge against your rubric for the soft dimensions like tone and completeness, and run deterministic verifiers for the hard ones: a check that every cited authority actually exists, a check that the jurisdiction in the answer matches the jurisdiction in the question, and a check that any organization the bot names is real and described correctly. Test against a realistic spread of questions and against a set of deliberately hard, high-risk ones, and put expert reviewers on the hardest cases before you deploy.
Evaluate one thing most teams miss: whether the bot asked the right questions, not only whether it gave a right answer. A system that answers fluently but never elicits the deadline or the jurisdiction is one a careful advisor would fault, and asking is the step that protects the person. You can also check an answer for surplus information and classify it: extra detail that is harmless, or extra detail that adds risk. Build your evaluation set to mirror the real spread of questions you expect, so the score reflects what people will actually ask.
What a chatbot still cannot do
The evaluation measures the quality of an answer as an expert would judge it, and it does not measure whether the person got a better outcome in their case, so a high score is a promising signal rather than proof of impact. The bot does not stand in for a lawyer on a complex matter, and it should hand off rather than improvise when a question crosses its risk threshold. And the model underneath will keep changing, which is the reason the durable work sits in the content, the wrapper, and the evaluation.
If you build one, start small
Pick one issue area you already have good content for. Ground the bot on that verified content with citations, and write the rubric targets and the safety rules for that area's high-risk scenarios. Stand up the evaluation harness and run it twice, once with the knowledge base and once without, so you can see the lift for yourself. Put two practitioners on the hardest cases, and pilot the bot in a limited way before you make it the front door of your service. The where-to-start guide has the staffing and the sequencing for a team of one, three, or five.