Chapter 3 Can I trust it?
Lesson 3.5:Test It on Your Own Matters (Your Own Benchmark)
A public leaderboard measures models on examples that someone else chose. Your team's past work can measure them on your own tasks. Each finished matter holds the documents that came in and the work your team sent out.
Turned into a test, these matters become a custom benchmark. Its score reflects the tasks that matter most to your team. And because it was never published, no model can have seen it in training, so there is no risk of contamination.
Why a public score isn't yours
A benchmark score is an average over many questions, and an average can hide the area you work in. On , models were fully right on 44% of health law questions on average. On family law questions, they were fully right on 15% Vals AI Legal Research Bench, Sep 2026 (opens in a new tab). The model with the best overall score led only four of the eight areas.
Family
Immigrationonly 22 questions
Constitutional / civil rights
Business & commercial
Criminal
Civil litigation
Administrative / regulatory
Health
→ Questions fully right · ringed: best of the three
The overall winner isn't the winner in every area of law.
Vals AI, Legal Research Bench, Sep 2026: share of questions fully right, by area of law, for the three top models. Areas with few questions have wide margins of error.
The conditions differ too. A benchmark usually sends each question straight to the model. Your team uses it through an app or a tool, with its own settings. In a 2026 Stanford audit, three major chatbots scored 3.4 points lower on average in their chat apps than through their API, the access that most tests use arXiv Wang et al., Sep 2026 (opens in a new tab). General rankings “can inform model selection but do not replace evidence about performance on the intended work” arXiv Amin, Sep 2026 (opens in a new tab).
A public score is measured on other people's questions, in other people's conditions.
Your past work is already a test set
Every finished task is one example for a benchmark. The input is what came in. The label is what your team sent out. In contract review, the input is the draft from the other side. The label is your team's redline, with the comments that explain each change. For advice, the input is the question and its documents, and the label is the note sent to the client or the business. For due diligence, the input is the data room, and the label is the list of issues found.
You don't need to create new data. You need to select and prepare the data you have. Pick 20 to 50 recent matters that the tool would really handle. Include routine matters and hard ones. Anonymise them, and put each one in the same shape: the input and its label. Also include matters with known traps. One example is a question built on a wrong assumption. Another is a contract where the clause that decides the matter is buried in an annex at the end.
Then split the matters. Use about two thirds to build your skill, the saved instructions that tell the model how your team does the task (lesson 2.6). Keep the last third as your test set, and don't look at it until the end. If you refine the skill while you watch its results on the same matters, you tune it to those matters. The score then rises, but the tool does not get better on new matters. Only the matters you kept aside give a score you can trust.
1/4Your finished matters sit in the archive.
Your finished matters already hold inputs and labels. Sort them, and they become a test.
Illustrative. A real test starts with 20 to 50 matters.
For open tasks, the model's text won't match your redline word for word. So compare points. Turn each change your team made into one point of a rubric. A clause your team left alone is a point too, because a needless change costs review time. Give more weight to the one or two points that decide the matter. wrote each point to be “individually necessary”, and all the points together to be “jointly sufficient” Vals AI Legal Research Bench, Sep 2026 (opens in a new tab).
How many matters you need
You don't need hundreds of examples to start. A 2026 guide to AI evaluations calls 20 to 50 simple tasks drawn from real failures a great start Anthropic Demystifying evals, Jan 2026 (opens in a new tab). That is enough to see when one tool does much better than another, or when a tool fails badly.
More matters still give a more precise score, though. Your test holds only some of the matters your team handles, so its score depends a little on which ones you picked, as with a poll. Every score comes with a margin of error: the range where the tool's true score most likely lies. The more matters you test, the narrower it gets. The figure below shows how much.
Matters in your test 30
How far apart the tools really are
Tool Atrue score 70%
Tool Btrue score 80%
At 30 matters, the ranges overlap: this test can't tell the tools apart yet.
A small test catches big gaps, not small ones.
Illustrative. Each bar shows the range of scores the tool could get on your test.
When the margins of two tools overlap, as in the figure, the test can't tell which one is better. You can choose on other grounds, such as cost or security, or add matters until the margins separate. The best ones to add are matters where a tool got something wrong in real work. Start with 20 to 50 matters, and add more over time.
What this means for your work
Once your test exists, run every new model or new version through it. Next to the score, record what each matter costs and how long it takes, because models with the same score can differ widely in price. To grade often, you can let a model grade the outputs, with LLM-as-a-judge. Check it once first: two colleagues grade a sample, the judge grades the same sample, and you read where they disagree.
Run the test again whenever something changes, because tools can change without notice. A 2026 study asked three AI services the same 240 questions every week for ten weeks. One of them got much worse between weeks five and seven, with no announcement PLOS One Wiese, Feb 2026 (opens in a new tab). Run each new model through your own test before you switch.
A test tells you whether a tool is good. The next lesson is about the other failure: output that was never checked by anyone.