Can You Use the Issue Classifier, and Build Your Own?

Tagging a person's problem with the right legal issue is the hinge that routing, retrieval, and triage all turn on. The cohort built a classifier for the LIST taxonomy using Quinten Steenhuis's FETCH method. This guide is whether you can use it, how to call it, how to build your own, and how its gaps feed back into the taxonomy itself.

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

A person types a few sentences about a problem. Before anything useful can happen, a system has to know what kind of legal issue it is: is this an eviction, a debt collection case, a benefits denial, a custody dispute. Get that wrong and every downstream step is wrong, the retrieval pulls the wrong content, the referral goes to the wrong program, the triage misreads the urgency. The classifier is the piece that does this tagging, and it tags into the shared LIST taxonomy so that the result means the same thing across states.

What it does

The classifier takes a description of a problem and returns the one or two best LIST codes, with a confidence level. When the description is ambiguous, it returns clarifying questions instead of guessing. It also flags two edge cases: when the text is not a legal problem at all, and when the problem does not fit any existing code, which is the signal that matters for keeping the taxonomy current.

The method, which is Quinten's

The classifier is built on FETCH, the Fast Ensemble Tagging and Classification Helper that Quinten Steenhuis of the Suffolk LIT Lab published at JURIX 2025 (arxiv.org/abs/2509.07170). FETCH makes three choices that a typical single-model classifier does not. It sends one prompt, carrying an abbreviated version of the taxonomy where each term is just its name and its parent, to several LLMs at once. It combines their answers by weighted vote, where a model's first choice gets full weight and its second gets half. And it generates clarifying questions when the models disagree. In Steenhuis's study on the Oregon State Bar's 244-code taxonomy, the ensemble reached 97.37 percent accuracy at hits@2, beating a single frontier model at about a third of the cost. That figure is Quinten's result on the Oregon taxonomy, not the cohort's number on LIST, and it is the reason the cohort adopted the method rather than inventing one.

The cohort's version

The cohort adapted FETCH to the LIST taxonomy, which now holds over 1,300 codes across twenty categories. It is a Python package with a command line and the option to wrap it as an HTTP endpoint. It runs an ensemble across whatever providers a team configures, returns the top two codes with a confidence level and follow-up questions, and costs about a cent or two per classification with small models. The cohort tested it against a ground-truth set as part of the knowledge base classifier work, and the deterministic checks carried the signal there too, the same lesson as the rest of the evaluation work.

Whether you can use it, and how to call it

Yes, and there are two ways. A team with engineering capacity runs the package itself: install it, set one or more provider keys, and call it on a single description or a batch, or point the command line at a file of questions. A team that cannot run a pipeline calls a hosted endpoint instead, the same classifier wrapped as a service the field can host, so a small team sends text and gets codes back without building anything. For incremental work, classifying one new query as it arrives, a single model inside an Airtable script is fast enough. For batch backfills, the full ensemble is the right tool.

Build your own, or use the shared one

The method is published and the package is small, so a team with the capacity can build its own straight from Quinten's prompt and the LIST taxonomy at taxonomy.legal. A team without that capacity should use the shared classifier rather than rebuild it. The value either way is comparability: when everyone tags into the same LIST codes, content and referrals travel across states, which is the whole point of a shared vocabulary.

How the gaps grow LIST

The classifier flags when a problem does not fit any existing code. Those flags are candidate gaps in the taxonomy, the problems people actually bring that the vocabulary does not yet name. Collected and reviewed, they become proposed new LIST terms. This is the feedback loop: classify, flag the misses, review the misses, add the terms that earn their place, and reclassify. The cohort's work on LIST grew it this way, which is part of why it is over 1,300 terms now. The flag exists in the tool. The review queue and the governance step that decides which candidates become real terms are the part the field has to set up, and they are what keep the taxonomy current instead of frozen.

Honest limits

An ensemble is better than one model and still not perfect. Ambiguous descriptions need the clarifying questions rather than a forced guess. And a classification is a starting point for routing, not a legal determination about the person's case.