Start here
The full explanation of this document type, including how it is versioned and published, sits on About functional agendas.
Capability list
Choose the scope that matches the system you are building or evaluating, then filter the list to the levels you care about. Task areas are grouped under four principles: accurate, safe, usable, and maintainable.
What this tool does, and the principles behind the task areas
A worker uploads an eviction notice. The tool reads it, checks it against the statute one defect at a time, and returns a list of flags, each one carrying the sentence in the notice that triggered it. A guided interview then asks about the defenses that never appear in a notice, such as habitability or a landlord who accepted rent afterwards. At the widest scope, the tool pre-fills the court response and a supervising attorney signs it off.
The work sits with a trained worker under supervision. The tool does not advise the tenant and it does not file anything on its own.
The four principles behind the task areas
| Principle | What it requires |
|---|---|
| Accurate | Every verdict traces to a statute and to a quote from the document. The tool flags what it cannot read rather than returning a clean result. |
| Safe | A person decides. A clean result never reads as legal confirmation, and no response leaves the organization without attorney sign-off. |
| Usable | The worker can move between the flag and the document in both directions, and can tell what every action in the interface means. |
| Maintainable | A legal collaborator can amend the rubric without a developer, and performance is published per defect against an adjudicated set. |
This agenda resolves the precision and recall tradeoff in one direction. Borderline language gets raised for review rather than passed silently, because a raised defense costs a worker a minute and a waived defense can cost a tenant their home. That choice makes the tool noisier than a detector tuned for precision, and the worker experience capabilities in task area nine are what keep the noise manageable.
Step one
What kind of system are you building or evaluating?
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 EVI-<task area>.<capability>,
for example EVI-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:
EVI-4.2 (notice-defect-spotter v1.0). This follows the identifier rule used
by the OWASP Application Security Verification Standard.
Scopes
This agenda holds one catalog of 49 capabilities. Each of the four scopes is a selection over that catalog, stating which capabilities apply to a deployment of that shape and at what level. A detector that never drafts a response does not need the response generation capabilities, and they show as not applicable rather than being deleted from the list.
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
This agenda comes from a two-quarter studio project that built and tested an eviction notice defect detector with a clinical partner. The evidence base includes a rubric covering nine to thirteen defects, an adjudicated synthetic benchmark scored against five label sources, think-aloud sessions with a clinic volunteer and a supervising attorney, and two adversarial red-team passes.
The document generalizes one build to a task type. Every recommendation carries evidence from a single team's experience rather than from validation across implementations. Treat it as a starting point, and tell us where it is wrong.
Draft for review. This agenda generalizes a two-quarter studio build of an eviction notice defect detector, developed with a clinical partner in winter and spring of 2026. The standards are proposed from that experience and have not been validated across implementations. Send corrections and additions to legaldesignlab@law.stanford.edu.
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 eviction notice defect spotting.
- Step 2
Conformance standard
The thresholds, the review gates, and the conditions that stop a pilot.
- Step 3
Evaluation protocol and test suite
The scored notice set and the per-defect rubric used to measure a system.
- Step 5
Reference implementation
The build described in code, with the rubric a legal collaborator can edit.
- Related
Eviction Answer worked example
The canonical worked example for the housing vertical, from notice to filed answer.
- Hub
Eviction Defense hub
Everything in the package, plus the organizations working on this workflow.