Reference

About Functional Agendas

A functional agenda is the list of everything a legal help AI tool of a given kind needs to be able to do. This page explains how the Commons writes one, how it is versioned and published, and how each audience uses it.

Applies to
Every functional agenda the Commons publishes
Updated
August 2026

What a functional agenda is

A functional agenda names the capabilities a tool needs, groups them by task area, and attaches a level to each one. The level tells a reader the difference between what a system must do before it meets the public and what remains a research target.

The structure follows the pattern used in web accessibility standards. Task areas break the work into parts. Each task area holds numbered capabilities. Each capability is written as one testable thing the system does, so it can be checked by a person or by a script.

A functional agenda does not tell you how to build the tool, and it does not set the passing scores. Those belong to the reference architecture and the conformance standard, which are separate documents in the same package.

Where a functional agenda sits in the sequence

  1. Step 1

    Functional agenda

    The capabilities a system of this kind needs, each one written to be tested.

    This document type
  2. Step 2

    Conformance standard

    The thresholds a system has to hit, the review gates, and the conditions that stop a pilot.

  3. Step 3

    Evaluation protocol and test suite

    The test cases and the scoring method that measure a system against the standard.

  4. Step 4

    Published results

    Scores for named systems, published on JusticeBench so that teams can compare them.

  5. Step 5

    Reference architecture

    A described build and the open-source implementation that goes with it.

  6. Step 6

    Course module and case studies

    The teaching materials that help a team run this workflow in their own organization.

Four ways people use one

  • Building a tool

    Filter to the required and critical capabilities for your scope, then download the CSV. Each capability is written to be testable, so the list moves into an issue tracker as acceptance criteria without rewriting.

  • Evaluating a system

    Use the capability identifiers as your measurement list. Ask the team to demonstrate each required capability on a live system rather than describe it in a document, and record the identifier next to what you saw.

  • Buying or funding a build

    Put the required capabilities for the stated scope into the solicitation or the grant condition, cited with the version. Ask an applicant to respond capability by capability using the same identifiers.

  • Setting your own requirements

    Read it as a wishlist you can edit. Tell us what to add, what to cut, and what your organization would refuse to deploy without. A comment that removes a capability is as useful as one that adds one.

How the Commons publishes and versions an agenda

These rules exist so that a capability cited in a contract, a grant condition, or an evaluation report still means the same thing a year later. They follow practice that is already established in other specification communities.

Levels and keywords

LevelKeywordWhat it requires
RequiredMUSTThe system does this before it serves the public.
CriticalMUSTA required capability where failure harms a person directly.
ExtendedSHOULDThere may be good reasons to skip one, and the reasons should be written down.
AspirationalMAYFew systems do these yet. They mark the direction of travel.

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 travel in the CSV and JSON downloads so that procurement language can be written directly from them.

Identifiers

Every capability carries a prefixed identifier, such as VOI-4.2, where the prefix names the workflow, the first number is the task area, and the second is the capability. Identifiers do not move or get reused inside a version. A retired capability keeps its number and is marked retired rather than removed, which is why task areas are not grouped by level. Cite an item with the version attached, in the form VOI-4.2 (voice-intake v1.0). This follows the identifier rule used by the OWASP Application Security Verification Standard, where a bare identifier means the current content and a version-prefixed identifier means one specific release.

Scopes

An agenda holds one catalog of capabilities. A scope is a selection over that catalog, which states which capabilities apply to a deployment of that shape and at what level. This separation follows the way NIST publishes a control catalog and then publishes each baseline as a profile over it. It means an organization can publish its own scope, saying what it requires locally, without forking the capability list.

Status and version

StatusWhat it means
Draft for reviewOpen for comment. Capabilities and levels can still change, and comments that remove a capability are welcome.
StableReviewed by the working group for that workflow. Safe to cite in a contract or a grant condition.
SupersededA later version exists. The document stays online at its own address so that old citations still resolve.

Versions run as major and minor numbers. A minor version adds capabilities or clarifies wording without changing what an existing identifier means. A major version can renumber, and it ships with a list of what changed. Each agenda page states its version, its status, and the date it was last updated at the top.

Formats

Each agenda is published as a filterable web page, a CSV, a JSON file, and a PDF produced from the print view. The CSV and JSON carry whatever the filters are showing, so a scope and level selection becomes a working checklist rather than a document to retype. Each download records the version, the status, and the scope it came from.

What an agenda is not

It is not an endorsement or a certification of any product. It is not a threshold: it says a system should compute deadlines in code, and the conformance standard says how accurate that has to be before a pilot. It is not a build plan. And it is not final. Every agenda published so far carries evidence from practitioner experience rather than from large-scale validation, and each one says so on its own page.

Comment on an agenda

Every agenda is open for comment while it carries the draft status. Send corrections and additions to legaldesignlab@law.stanford.edu, naming the capability identifier and the version you are looking at. Tell us what your organization would refuse to deploy without, and what you would strike.