Cohort forming
Brief Help Legal Questions
Help somebody who describes a legal problem in their own words get an answer that is right for where they live, a plan they can act on, and a route to a person.
Help somebody who describes a legal problem in their own words get an answer that is right for where they live, a plan they can act on, and a route to a person.
This page is the shared target for this situation. Any court, legal aid office, or builder working on it in their own region can take the vision, the blueprints, and the standards here instead of starting over, and set the parts that are local to them. The point is that the same work is not designed from scratch in every county.
Does this match how it goes where you are? Leave a note on this workflow.
Somebody types what happened to them rather than a legal category, and wants to know what it means and what to do next. Before any answer, the system has to work out where they are and what they are actually asking, and which missing facts would change the answer.
The answer has to come from real content about that jurisdiction, in words the person can use, and it has to be honest about what depends on facts nobody has yet. An answer that explains the law and stops there leaves the person where they started, so the plan for what to do next is the part they act on.
A wrong deadline is the fastest way to lose somebody a case, so the dates come from a rules table rather than from generated text. The same goes for the forms, which have to be the current version for that court.
The system has to know when to stop. It refuses the questions it should refuse, spots danger in what somebody describes, and hands off to a person with what has already been collected rather than starting them over.
This workflow is shared infrastructure. The same question answering sits behind housing, debt collection, reentry, and public benefits work, which is why it is built once rather than separately in each area.
A person searches, lands on material written for another state, and cannot tell whether it applies to them. The organizations that do answer these questions answer them one at a time, by email or on a phone line, and the answer reaches one person.
A person writes the problem in their own words and gets an answer for their jurisdiction, with the facts that would change it named, a plan they can act on, the deadlines that apply, and the current form for their court. The system says when it does not know, refuses what it should refuse, and hands the person to somebody who can help with what has already been collected.
This is one vision, taken from the functional agenda and from research on how people judge legal answers. Technology could play out in other ways here, and the cohort weighs them against this one.
Who this serves: People with a legal problem who have no lawyer, the organizations running question and answer services and hotlines, the courts whose self help pages people land on, and the builders of any tool that has to answer a legal question.
Where this came from: The functional agenda for this workflow and the research findings behind it. This page is built from those materials. The cohort for this area picks it up from here.
The step-by-step agenda and the functional agenda are both open for review. The cohort writes the standards from the answers that come back, and this page carries them when they exist.
What a system here has to do, written as the work in order and in plain words, with the question the Commons team wants answered about each part. Start here if you answer these questions for a living and want to say what a tool needs.
Read the step-by-step agenda →What the system must do, with every capability numbered, sorted by level and by the scope of the system being built, and written so a builder can build against it and an evaluator can test against it. Several capabilities are worded the way they are because of research findings on how people judge legal answers.
Read the functional agenda →How anyone judges whether a builder did this well: whether the answer is right for the jurisdiction the person is in, whether the deadlines come from a rules table rather than from generated text, whether the system refuses when it should, and what a supervising attorney has to correct.
The rest of the package follows once those exist. It covers the baseline numbers, the procurement and contract terms, the reference architecture, which says what any jurisdiction can take as it is and what each place has to set for itself, the stories and materials from teams who have already built something here, and the tests.
The knowledge bases cohort is forming now, and this is one of the workflows in front of it. Members bring what they answer every day, argue about what a tool here has to do, and read the drafts.