Common infrastructure tools, built once and used everywhere
A tool travels across teams and platforms because you reach it rather than rebuild it. The same reader, classifier, or connector can serve a team on a commercial assistant, a team on a self-hosted platform, and a team running its own code. We are gathering the tools worth building once for the whole field, and we want to know who is already working on each one. Working on one of these? Raise your hand on its card. The cohort has already built some of them, and the catalog report says what exists, how ready each piece is, and what is not ready yet.
Reads text out of a scanned or photographed document and matches it into structured fields like the issue, the jurisdiction, the parties, the dates, and the amounts. It attaches the source page and a confidence level to every field it extracts. Before building, a team can also use it to test OCR on a small set of its own filings and to sort a filing into its parts, such as the complaint, the affidavit, and the bill of sale.
Turns real, PII-rich materials into realistic fake versions you can safely share and test against, including poor-quality images that mirror what people actually upload. It builds on the PII masker’s detection step.
Pulls client, case, and court-record data from the systems an organization already runs, so a person never re-enters what a system already knows. It can also pull a case’s documents through a case system push, an API, or a court-record scraper, and it tags every item with its case and its source.
It records where each workflow's documents and records live in each jurisdiction, who may access them, and what approvals a court requires before a tool may use them.
Fills official court and government forms and assembles complete filing packets from a person's answers, so they hand in the right paperwork the first time. It can also fill templates from fields extracted from case documents and from a reviewer-approved conclusion, and write the result back to a case management system where the court or organization allows it.
Files a document into a court's electronic filing system and returns the receipt or rejection. Because most courts run on a small number of common backends, one connector can reach many jurisdictions at once.
Runs a tool against gold-standard legal questions on a schedule and watches for hallucinations and quality drops over time. It also holds the test suites a team runs before a pilot, including field-level tests and a gold test set labeled by trained coders, with agreement between coders scored using Gwet’s AC1.
It tracks a running workflow over time, including accuracy on spot-checked cases and how reviewers confirm or override findings, and it sends each error back to its cause.
Checks every link, organization name, and phone number in an AI answer against your real directory, and flags the hallucinated citations and misattributed numbers an LLM judge waves through. Runs as a check in your evaluation harness, next to a model judge.
Lets experts and annotators code and label legal documents and datasets, so a team can build the test sets, training sets, and gold label sets that everything else is measured against. It holds the label scheme, shows each document with the fields to mark, keeps track of who labeled what, and shows where annotators disagree so the scheme can be fixed before the labeling scales up.
Watches court opinions, standing orders, and rule changes, and flags the ones that change how a guide or tool should work. A statewide legal aid organization is building an opinion alert tool for its own appellate opinions.
Tracks bills as they move, so teams see what is changing before it takes effect. A statewide legal aid organization is building a legislative tracker for its own state.
It gives a team interview guides, scenario walkthroughs, and a flowchart template for turning statutes and practitioner judgment into a draft flowchart of rules with citations.
It holds every rule a workflow applies, with its citation and version, in a list a lawyer can edit without code, and it applies those rules the same way every time.
Every project has to decide what belongs to the place it runs in and what
can be held in common. The tools on this page are the second kind.
Localization
What needs to be customized for your place:
Your organization's setup and the community it serves
Your rules, procedures, and practices
Your data structures and who has access to them
Your tech stack, licenses, costs, and policies
The common spine
What does not need to be customized, and can be shared across every
organization that decides to work in coordination, even with different builders:
Reference architecture
Common blueprints
Standard agendas, tests, and tooling
For each project, the work is to define what goes in the common spine and what
stays local. That line is what makes a tool worth building once.
Raise your hand
Are you building one of these?
Tell us what you are working on, and we will connect you with the others building it, add it to the commons, and help the field build it once instead of many times over. If you are using one of these and would build on it, we want to hear that too.