Start here
The full explanation of this document type, including how it is versioned and published, sits on About functional agendas.
Capability list
Filter the list to the levels you care about, or search it. This agenda has no scope selector, so every capability applies to every deployment.
What this workflow covers, and the principles behind the task areas
A person has a legal question. They type it or speak it in their own words. The system returns an answer grounded in content the deploying organization stewards, along with the steps to take next, the deadlines that apply, the forms involved, and the human services that can help.
Three audiences ask these questions, and they need different things from the same system.
| Audience | What changes for them |
|---|---|
| A member of the public | Plain language, an action plan they can follow alone, and an honest refusal when the matter is beyond self-help. |
| A navigator or community advocate | Referral accuracy, eligibility detail, and a clear account of what to tell the person they are helping. |
| A junior staff member or volunteer | Citations to authority, the reasoning behind the answer, and a statement of what to verify before relying on it. |
The system serves all three by varying the presentation and the level of citation. The underlying answer stays the same.
Where this workflow ends and another begins
| This workflow | A different workflow |
|---|---|
| Starts from a question and ends with an answer and a plan | Voice AI intake starts from a caller and ends with an eligibility decision and a case record |
| Recommends the right form and explains it | Document assembly fills the form out |
| Names the service that can help | Referral routing scores and ranks services against capacity |
| Explains what a document means when asked | Document diagnosis takes an uploaded document as its starting input |
A single deployed product often crosses these lines. The agendas stay separate so that conformance can be tested one workflow at a time.
The five principles behind the task areas
| Principle | What it requires |
|---|---|
| Grounded | Every substantive statement comes from content the deploying organization stewards and can correct. The system does not answer from the model's general knowledge. |
| Actionable | The person leaves knowing what to do, by when, and with what. An answer that is correct and leaves the person no better able to act has failed. |
| Bounded | The system knows what it does not cover, says so plainly, and sends the person somewhere real. |
| Supervised | A person can see what the system produced, review a sample of it, and correct it through content or configuration rather than through a rebuild. |
| Accountable | Performance is measured against a fixed set of questions, the measurement is repeated after every change, and the record can be shared. |
Research with 46 community members and 21 legal experts found that actionability matters more to users than precision. A vague answer that is technically correct scores worse than a specific answer that is slightly imprecise. That finding sits uncomfortably beside a grounding requirement, and this agenda resolves it in one direction. The system should be specific about what the content supports and silent about what it does not, rather than hedging everything.
Step one
How to read the levels, and how to cite a capability
| Level | Keyword | What it requires |
|---|---|---|
| Required | MUST |
The system does this before it serves the public. A deployment that misses a required capability has a failure mode the field has already documented. |
| Critical | MUST |
A required capability where failure harms a person directly. These are the items to test hardest and to review by hand. |
| Extended | SHOULD |
There may be good reasons to skip one of these, and the reasons should be written down. Most are what a mature deployment adds after its first year. |
| Aspirational | MAY |
Few systems do these yet. They mark the direction of travel, and they are the capabilities most likely to change in the next version. |
The keyword column follows BCP 14, the convention used in internet specifications, where the capitalized words carry the requirement level and ordinary prose does not. The keywords appear in the CSV and JSON downloads so that they can be pasted into a solicitation or a grant condition.
Identifiers
Each capability carries an identifier in the form BHQ-<task area>.<capability>,
for example BHQ-4.2. Identifiers do not move or get reused inside a
version. A retired capability keeps its number and is marked retired rather than deleted.
Because numbers can change between versions, cite an item with the version attached:
BHQ-4.2 (brief-help-qa v1.0). This follows the identifier rule used
by the OWASP Application Security Verification Standard.
Scopes
This agenda has no scopes. Question answering does not yet divide into shapes of deployment that the field has agreed on, so every capability applies to every deployment. Tell us if your deployment needs a narrower selection, and which capabilities you would put in it.
Formats
This page is the reference view. The CSV and JSON downloads carry whatever the filters are currently showing, so a scope and level selection becomes a working checklist. The print view produces a PDF of the same selection. Every download records the version, the status, and the scope it came from.
Task areas and capability counts
Jump to a task area
Where this comes from, and how to comment
The capability list draws on published user and expert research, three public audit reports of live legal help systems, and practices that deploying teams have described in conference presentations and technical webinars. The evidence base is set out in full further down this page.
This is a cross-cutting workflow rather than one tied to a single legal issue. The companion conformance standard, which sets the thresholds and the review gates, is in development.
Draft for review. This is a working draft. The capability list and the levels are both open to challenge, and a comment that removes a capability is as useful as one that adds one. Send corrections and additions to legaldesignlab@law.stanford.edu.
Evidence base
Where the evidence comes from
User and expert research
The quality and safety criteria behind task areas two, three, seven, and eight come from Hagan (2024), Measuring What Matters: Developing Human-Centered Legal Question and Answer Quality Standards through Multi-Stakeholder Research, presented at JURIX 2024. The empirical base is 46 community member interviews and 21 expert evaluations.
Five findings from that research diverge from how legal AI answers are usually judged, and they are the reason several capabilities here are worded the way they are.
- Actionability matters more to users than precision. A vague but accurate answer helps less than a specific answer that is slightly imprecise.
- Some accurate information is dangerous without context. Stating a right without describing the risk of exercising it is a safety failure rather than a neutral act.
- Citations do not raise perceived quality for public users. They are neutral, and citation density is not a proxy for a good answer.
- Over-caution is a failure mode. Repeated advice to consult a lawyer, where the person could act, makes the answer worse.
- Procedural errors are the most harmful kind. Wrong deadlines, wrong courts, wrong forms, and wrong filing steps do more damage than admitted uncertainty.
Published audits of live systems
Three public audit reports from a university law and technology center inform task areas five, seven, and nine. Two examined live public-facing systems, and one examined the cost of scoping a new build for a statewide legal help site. Their published findings include rules from the wrong jurisdiction presented as local law, absent confidentiality disclosure, indefinite session retention, a defect that allowed access to another user's data, high abandonment from an embedded entry point, and a distribution of answer quality scored on a five-point scale running from helpful and actionable down to harmful.
Publicly documented production deployments
Several capabilities in task area nine reflect practices that deploying teams have described publicly in conference presentations and technical webinars. Those practices include maintaining content in one place and syncing rather than duplicating it, holding a fixed control question set and re-running it after prompt changes, reviewing thousands of real conversations by lawyers, correcting failures by changing content or the system prompt rather than the model, moving to automated risk flagging as volume grows, and scrubbing personal information before logging.
The rest of the package
Other documents for this workflow
A functional agenda is one of the documents the Commons produces for each workflow. These are the others for brief help question answering.
- Step 2
Conformance standard
The thresholds, the review gates, and the conditions that stop a pilot.
- Step 3
Evaluation protocol and test suite
The control question set and the scoring rubric used to measure a system.
- Related
Justice Knowledge Base content standard
The data contract for the content this workflow retrieves its answers from.
- Library
Standards library
Every functional agenda and conformance standard the Commons publishes.