How Do You Tell Whether a Legal AI Tool Is Any Good?

The strategy guide said the field should change the incentives around the models by measuring them in public. This is how that measurement works, and it is the method any team can use to find out whether a legal AI tool, its own or a vendor's, is good at the tasks it cares about. The value is simple: you can find out before you deploy, instead of after. The method is built, it is cheap to run, and it is honest about the one thing it does not yet measure, which is whether better answers produce better outcomes for real people.

Common Legal Help AI. Working draft for comment. Margaret Hagan, Stanford Legal Design Lab.

The strategy guide named four ways to change how a foundation model behaves, and the fourth was to change the incentives around the models by measuring them in public. The grounding guide kept pointing forward to the scoring machinery that produced its numbers. This guide is both of those things at once, because it is how the measurement works, and it is the method any team can use to find out whether a legal AI tool is good at the tasks the team cares about.

Here is the value to you, stated first. Today a legal aid director sits through a vendor demo, the answers look good, the tool gets deployed, and the failures show up in production, where a real person with a real legal problem is on the other end of them. There is no shared way to tell, in advance, whether a tool actually works. This guide describes one, and it is cheap and repeatable enough that a small team can run it. The cohort built it over five rounds of testing in May 2026, and every component is open and reusable.

Start with the task, not the tool

You cannot ask whether an AI tool is good in the abstract. You can only ask whether it is good at a specific task. The strategy guide described the Legal Help Task Taxonomy on JusticeBench, which lays out fifty tasks across the work that people and providers do, and that taxonomy is the unit of evaluation. The grounding guide reported evidence on one of those tasks, which was legal question-answering, and it was careful to say that the evidence covered that task alone.

The measurement method is wider than that single task. The cohort built six task-specific test suites, one each for brief legal help question-answering, referral matching, user classification, service classification, OCR and document extraction, and PII masking. Each suite combines the right datasets with a rubric written for that task, so the score answers a specific question, such as whether the referral tool sent the question to the right page in the right state, rather than the vague question of whether the AI seems good. The task is the thing you evaluate, and the suite is how you evaluate it.

Picture two teams choosing what to evaluate, as an illustration rather than a run we have done. The first team operates a referral tool that takes a typed problem and points the person to a legal aid program. The team does not ask whether the tool is good in general. It runs the referral matching suite, which scores whether the tool sent the question to the right page in the right state, whether the program it named actually serves that county, and whether it admitted when no good match exists. The second team operates a document explainer that reads an uploaded notice and tells the person what it is. That team runs the brief-help and document datasets through the tool and asks whether it identified the document type correctly, named the real deadline printed on it, and pointed to the form a person would actually need. It is the same method on two different tasks, with two different questions, and each question has an answer.

Stand up the harness

The harness is promptfoo, an open-source evaluation platform that AI teams use in production across the industry. Building on a standard tool rather than a homegrown one means the cohort's work plugs into something other people already maintain, and a state team can fork the setup without depending on Stanford to keep it alive. The platform runs a matrix: it takes a set of questions, a set of conditions to compare, and the models you want to test, and it scores every combination of them.

The grounding guide's conditions, which were the bare model against directory grounding against full-content grounding, were promptfoo conditions, and the same structure compares anything you want to compare. You can put one vendor against another, one model against the next, or this version of your tool against last month's. Each round in May cost under twenty-five dollars and ran in under ninety minutes, and that is the part that makes the method usable by a team without a research budget.

Here is where the matrix earns its keep, again as an illustration. Suppose a court self-help center is choosing between two intake tools, each of which is supposed to read a person's description of their problem and sort it into the right legal issue and the right urgency level. The center loads its own set of example intake questions, sets the two vendors as the conditions, and lets the harness score every question through both tools. The output is not a sales impression from a demo. It is a side-by-side table showing that one tool tagged the legal issue correctly more often while the other one flagged emergencies more reliably, which is the actual tradeoff the center is trying to decide. The same setup, pointed at a single tool across two dates, answers a different question, which is whether the center's eviction question-answering assistant got better or worse after someone changed its prompt last month.

Score in layers

The scoring is where the real lesson lives, and it is the lesson the grounding guide kept deferring to this one. Every answer is scored by three independent components, and they are not interchangeable.

The first component is an LLM acting as a judge, scoring each answer against a rubric. This is the part most people mean when they say they evaluated an AI tool, and on its own it is not enough. Across the first rounds of testing, with the first rubric, the judge passed one hundred percent of the answers, and it could not tell the grounded answers from the bare ones. Every bit of real differentiation came from somewhere else.

The second component is a deterministic verifier, which is a plain piece of software that checks facts rather than judging quality. It scans each answer for citations and checks them against ground truth. It asks whether a cited URL actually resolves or returns a 404, whether a named organization appears in the directory of 1,648 active legal aid organizations or was invented by the model, whether a phone number is attached to the right organization, and whether the answer points a person to a service in the wrong state. These checks are cheap, they run in milliseconds, and they produce findings that are true with certainty. When the verifier says a URL is hallucinated, the domain literally does not resolve. That is a different kind of claim from "the judge thought the answer was a little vague," and it is the kind you can publish without an asterisk.

The third component is a second deterministic check, which we added once we saw the model putting quotation marks around text that was not actually in the source. It pulls every quoted phrase of five or more words and checks whether it appears in the article the model claimed to be quoting. A model that paraphrases under quotation marks is misleading a user about what the authoritative text says, and no quality judge catches that reliably. A substring check catches it every time.

The deeper lesson sits on top of these three components, and every cohort member should carry it into any procurement decision. How you measure determines what you see. The grounding guide told part of this story. In one round, full-content grounding tied with the simpler directory grounding, and the tie was real on the rubric we were using at the time. We sharpened the rubric to look for specific actionability, source fidelity, honest uncertainty, and quotation accuracy, and the tie turned into a clean win for full-content grounding. Then we took the sharper rubric to the high-risk questions and added scenario-specific criteria, and the clean win became the nuanced, content-dependent picture the grounding guide reported. The system did not change between those rounds. The measurement did. An evaluation actively shapes which differences you can see, and a weak evaluation will tell you a tool is fine when it is not.

Putting the three components together produces a map of how legal AI fails, and the failures fall into four layers. The first layer is citation and attribution, which covers invented URLs, wrong-state organizations, and wrong phone numbers, and the deterministic verifier catches it. The second layer is source fidelity, which covers paraphrase passed off as a quote, confident invented citations, and vague answers that give no usable step, and the sharper judge criteria and the quotation check catch it. The third layer is scenario-specific legal reasoning, which covers missing the clarifying question a situation requires or walking into a failure an expert flagged in advance, and a judge that has been told what the scenario demands catches it. The fourth layer is infrastructure, which covers the model that returns an API error instead of an answer, and it is easy to ignore in a research run and impossible to ignore in a deployed tool. A real evaluation has to cover all four layers, because a tool can pass one and fail another.

Picture how the three components score a single answer, as an illustration. A brief-advice tool answers a question from a tenant in Cook County who has a few days to respond to an eviction filing. The LLM judge reads the answer and rates it clear and reasonably complete. The deterministic verifier then checks the answer's links and finds that the legal aid phone number the tool gave belongs to an organization one county over, which the judge did not notice and which the tenant would not notice either, until the call went nowhere. The quotation check finds that the tool wrapped quotation marks around a sentence it attributed to the Illinois eviction statute, and that sentence does not appear in the statute. That is one answer, three findings, and two of the three are exactly the kind a quality judge working alone would have missed. Now picture the same layered scoring on a deadline calculator, where the third layer matters most. The tool's tone is fine and its citation is real, but it counted calendar days when the rule counts court days, and the scenario-aware check is the thing that catches that the deadline it gave a person is simply wrong.

The rubrics, and why they are built from the field's own standards

A rubric is the part of the method that decides what good means, and a generic rubric will not do for legal help. Each task gets a rubric shaped to that task, because what makes a good answer to a tenant's question is not what makes a good redaction or a good referral. The most developed one is the rubric for brief legal help question-answering, which scores eight dimensions: legal accuracy, completeness, jurisdiction precision, safety treated as a veto rather than as one dimension among others, tone, actionability, personalization, and the dimensions specific to the issue area, each on an anchored zero-to-three scale with a written description of what each score means. Other tasks carry their own shape. The PII masking rubric, for instance, scores five checks behind a set of hard fails, where one visible Social Security number fails the whole output no matter how it scores elsewhere, and the classification and referral suites score against a known correct answer. What the rubrics share is not a fixed list of dimensions. It is a set of habits: anchored scales so two reviewers land in the same place, safety handled as a veto rather than averaged away, and the standard drawn from the field rather than from a generic notion of helpfulness.

What makes the question-answering rubric trustworthy is where it comes from. It is built on research that interviewed 46 community members and collected evaluations from 21 legal experts, and five findings from that research are written directly into the judge's instructions. Actionability matters more than raw accuracy. Some accurate information is dangerous without context. Citations are neutral and do not earn a quality bonus. Over-cautious disclaimers lower the score rather than raise it. Procedural errors are the worst kind of error. Most off-the-shelf AI judges do not score this way, because they were built to measure general helpfulness, not whether a frightened tenant gets a usable next step. The rubric is where the field's real standards, drawn from real people and real experts, get encoded into the measurement, and that is the difference between an evaluation grounded in the work and one that is blind to it.

Here is what those five findings do to a real score, as an illustration. Two brief-advice tools answer the same question from a tenant who has just been served with an eviction case. The first tool gives a careful, accurate overview of eviction law and ends by telling the tenant to consult an attorney. The second tool tells the tenant the specific thing to do this week, which is to file a written answer with the court before the deadline, and it names the form to use. A generic helpfulness rubric might rate the first answer higher, because it is thorough and cautious and hedged. The cohort's rubric rates the second one higher, because actionability outranks completeness, because an over-cautious non-answer loses points rather than earning them, and because a tenant who follows the first answer can still miss the deadline and lose the home. The rubric is the place where the field's judgment, that a usable next step beats a careful essay, becomes a number a tool can be measured against.

The data you need ready

An evaluation is only as good as the labeled data behind it, and this is the part a team cannot improvise the night before a vendor meeting. The cohort built eleven datasets and the six test suites that draw on them. The datasets include roughly three hundred common brief-help questions with gold labels for issue, jurisdiction, and recommended next step. They include the 192-question High-Risk Challenge set that the grounding guide's hardest round drew from. They include fifty refusal-and-escalation cases that test whether a tool declines to give a substantive answer on suicidal ideation, imminent violence, or a request to lie to a judge, which Siobhan Durcan frames as the Gate 0 test, the one that most embarrasses a tool if it is missing. They include thirty multi-turn dialogues that catch the failures single-question demos hide, five hundred service descriptions for testing classification, and two hundred query-to-webpage gold pairs that test whether a referral tool sends a real question to the right page in the right state. Each dataset, once it is labeled, feeds more than one suite.

This is where the value to a website operator becomes concrete, because the datasets answer three questions that are hard to answer today. The first question is what quality of AI your users are actually getting, and you find out by running the suites on your current chatbot, your search, and your intake tool. The second question is whether to sign with a particular vendor, and you find out by asking the vendor to run the suites and share the scores, and by treating a refusal as its own answer. The third question is whether your staff's build time is well spent, and you find out by setting go and no-go thresholds before launch instead of after. None of these questions has a good answer today, and all three have one with a test suite in hand.

Picture a team putting these datasets to work, as an illustration. A legal aid organization has a chatbot live on its website and wants to know its real exposure. The team runs the fifty refusal-and-escalation cases through the bot and watches what happens when a user types that they are thinking of hurting themselves, or asks how to hide assets from a court. If the bot gives a substantive answer where it should step back and escalate, the team has found its headline risk in a test run rather than in the news. A second team, deciding whether to extend a brief-advice tool from housing into a new issue area, runs the High-Risk Challenge questions for that area and sets a rule in advance, which is that the tool does not go live on the new topic until it clears a threshold on the safety suite. The dataset turns a launch decision from a gut call into a gate with a number on it.

Who runs it, and what it looks like in practice

For the scores to mean anything beyond a single team, a neutral party has to hold the benchmark, because a vendor cannot be trusted to grade the test it is sitting for. The credible arrangement is a convener working with academic and research partners, with subject-matter experts contributing the scenarios and the gold answers and funders covering the upkeep. This is the same division of labor the strategy guide described for the open content feed, where the states and the experts supply the substance and a convener holds the shared infrastructure on behalf of the field.

The experts do more than write scenarios, because they are also how the field knows it can trust the AI judge to do the bulk of the scoring. The workflow puts the same answers in front of five to seven experts, who score them blind, without seeing which model or which condition produced each one, and then the field compares the experts' scores to the judge's. The judge earns the right to score at scale only when its agreement with the experts clears Cohen's kappa of 0.6. Until it clears that bar, the experts are the measurement and the judge is only a candidate for it.

Here is what the finished version could look like, and I am describing a goal rather than a thing that exists today. Picture a public scoreboard on JusticeBench with scores broken out by task and by suite. A legal aid director comparing three vendors asks each one for its scores and reads the refusals as answers. A funder writes a required passing score on the safety suite into a request for proposals. A model company that sees its jurisdiction-precision score is low has a public reason to raise it. The Five Gates that the field already uses to decide whether a tool is ready stop being a checklist of opinions and start being a set of numbers that a tool either clears or does not.

Picture the expert side of this on a specific task, again as an illustration. To calibrate the judge for the document explainer, the convener shows seven legal aid attorneys a stack of explainer outputs, blind, with no labels for which tool or which condition produced each one. The attorneys score whether each explanation correctly identified the document and the deadline on it. Where the attorneys and the AI judge agree often enough to clear the kappa bar, the judge takes over the volume scoring for that task, and where they do not agree, the attorneys stay in the loop and the rubric goes back for another pass. On the public side, picture the referral-matching scores for several tools sitting together on one JusticeBench page, so that a director in a new state can see which tools have actually been tested on routing and which have not, before a single sales call.

What this method does not measure

The honesty these guides owe their readers applies here too. This method measures expert-judged output quality, and it does not measure whether users get better legal outcomes. The distance between an expert rating an answer highly and a tenant keeping her home is large and unproven, and closing it requires real user studies, ideally compared against legal aid hotline interactions, which is a separate phase of work beyond this grant. The expert review pass that calibrates the judge is in progress rather than finished. The datasets need a versioned public release with provenance and clear licensing before anyone outside the cohort should lean on them. Coverage of languages other than English barely extends past Spanish. The method is sound and usable now for procurement and pre-deployment decisions, and it is not yet a finished public benchmark, and we will keep saying so wherever the data is thin.

Here is the limit made concrete, as an illustration. Suppose the document explainer clears every bar in this guide. The attorneys agree that it identifies notices correctly, the verifier confirms that the deadlines it cites are real, and it scores well on its suite. The method still has not told anyone whether the tenant who read the explanation understood it, acted on it in time, and kept the home. A high score on the explanation is necessary, and it is not sufficient, and only a study that follows real people to their outcomes can close that gap. These guides stay careful about this because the distance between a good answer and a good outcome is exactly where overconfident claims about legal AI tend to live.

What comes next

This guide answered how the field can measure quality across the whole task taxonomy rather than argue about it. The coverage guide takes that lens to the bigger question, which is how the field builds a real read on AI performance across all fifty tasks when only one has been measured so far.

The question of who keeps a benchmark like this credible over time, funded and neutral and current, is one that no single state can answer alone. That is the subject the national-leadership guide takes up.