Worksheet · LC-R02
Evaluation-gates worksheet
Connect a requirement to test evidence, visible coverage gaps and a named release decision.
Use this when a release review needs to establish what the evaluation results support and what remains untested.
By Sunil Mathew, co-authored with Claude.
Read the worked example, then copy the thirteen-column table into your own document or spreadsheet. Use one row per requirement; the number of rows depends on the system.
What this helps you decide
Begin with an observable behaviour the system must demonstrate. Define unacceptable outcomes before the release meeting, then name who owns any discretionary trade-off.
Choose and justify thresholds for your use case. This worksheet supplies no universal pass percentage or production-readiness score.
Worked example
Illustrative case, not a claimed customer incident.
A refund assistant may prepare a recommendation but must not issue a payment without authorisation. A release-blocking check tests whether missing or invalid authorisation prevents the action across the chosen paths. A separate human review assesses whether the unresolved response is understandable.
The first property can be checked against system state. The second needs a suitable review rubric. Passing both on the chosen cases does not establish that all future inputs are covered.
Complete the gate table
Record the system version, cases, expected behaviour, grader, result, evidence, coverage gaps, decision owner and consequence of failure. Use the review questions to check whether the proposed evidence addresses the requirement.
| Gate element | Review question |
|---|---|
| Requirement | What observable behaviour are we examining? |
| Coverage | Which ordinary, difficult, incomplete and adversarial cases are included? |
| Grader | Is code, model-based grading or human review appropriate? |
| Grader validation | How do we know the grader detects the failure that matters? |
| Repeatability | Could variable output change the result across trials? |
| Consequence | Does failure block release or require a named decision? |
| Evidence | Can another reviewer reproduce or inspect the result? |
| Gaps | What has not been tested, and who accepts that uncertainty? |
The gate table
Fill in the empty cells for one requirement, then add rows as needed. There is no total-score column: a critical failure and a minor trade-off need their own treatment.
| requirement | system_version | case_set | expected_behaviour | grader | grader_validation | threshold_and_reason | result | coverage_gaps | evidence | decision_owner | failure_consequence | review_date |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
The file is the table above, with the same column names. There is no PDF: printing this page, or saving it as a PDF from the print dialogue, gives you the whole of it as a form.
Conduct the review
Separate release-blocking requirements from discretionary trade-offs. Record disagreements, the final decision and who owns it.
Re-run relevant checks when the system, prompt, model, tools or permissions change. Keep production monitoring alongside pre-release evaluation; the tested case set has a defined scope.
Next inspection: Choose one passing result. What does it establish, what does it leave open and what should be tested next?
For background on grader types, see Anthropic's Demystifying evals for AI agents.
Build the surrounding evidence
- Use the Workflow Cost Limits Worksheet to specify operating limits and tests.
- Use the Deployment checklist to connect release checks to owners and recovery paths.
- Use the Architecture decision record to preserve an accepted trade-off and its unresolved questions.
Practise building the evaluation with the system
Compare the Agentic Systems programmes to choose the depth of build and review you need. If a whole team needs to develop a shared approach, explore enterprise learning.