Create an evaluation record with cases, expected behavior, separate scores, and a justified release decision.
Define what must happen
An evaluation starts with a task and a checkable outcome. First, describe what the system should do and what it must never do.
Observable checks turn vague goals into evidence. Replace “helpful answer” with “states the current deadline and identifies the source passage.”
Task success may depend on an action outside the answer. Therefore, inspect the resulting record when a system claims it completed a change.
Build a useful case set
Representative cases should reflect the work you expect. Include ordinary requests, missing evidence, conflicting inputs, and actions outside the system’s authority.
Repeated trials help expose variable behavior. Run a case more than once when inconsistent answers would affect your decision.
A held-out set contains examples you did not use while adjusting the system. Otherwise, improvements may reflect familiarity with your test questions.
Write a rubric before testing
Separate dimensions make trade-offs visible. Score source support, required content, appropriate uncertainty, and permissions independently.
Critical checks must not disappear inside an average. Define which failures block the proposed use before seeing the results.
Review disagreements are useful evidence about the rubric itself. Ask two reviewers to score several examples, then clarify ambiguous criteria.
Compare two fictional candidates
A fictional assistant drafts equipment-policy answers for staff. The following invented results describe ten fixed questions tested once per candidate.
Candidate B improves source support from eight answers to nine. However, it also exposes restricted material in one answer.
The decision is to reject B for this release under the stated confidentiality gate. A higher content score cannot override that failure.
| Check | Candidate A | Candidate B | Interpretation |
|---|---|---|---|
| Supported answer | 8 / 10 | 9 / 10 | Content improved on this sample |
| Required details | 9 / 10 | 9 / 10 | No observed change |
| Restricted-data disclosure | 0 / 10 | 1 / 10 | B fails the critical gate |
| Release conclusion | More testing needed | Do not release | Neither result proves general safety |
Record enough to reproduce
An evaluation record includes the case ID, input, expected behavior, and observed result. Also record the prompt, model, source version, and application configuration.
A failure note should identify the actual mismatch. “Answered from retired policy” is more useful than “bad answer” when deciding what to repair.
The comparison boundary must remain clear. Ten teaching examples can reveal defects, but cannot establish a reliable real-world failure rate.
Practice: defend the release decision
Your exercise adds two questions involving missing evidence and two involving restricted information. Write the expected behavior before drafting any answers.
Your evidence packet should contain a rubric, case records, and one short recommendation. Use fictional material and test manually if you have no AI service.
A strong response distinguishes observed improvement from release readiness. Explain which failure blocks release and which uncertainty requires more testing.
Compare with the worked answer
Worked answer: Reject candidate B for the stated use. Investigate the disclosure, repair the access boundary, and retest related cases. Keep the content improvement as a separate finding. Candidate A still needs broader evidence before approval.
What to carry forward
Create an evaluation record with cases, expected behavior, separate scores, and a justified release decision.
Show your reasoning with the exercise above. Keep the evidence, the decision, and the remaining uncertainty together.