Try to break your own result

IDEA 1

Write checks before judging outputs

An evaluation case supplies an input and a judging rule. Include normal requests, exact boundaries, missing evidence, and disallowed actions. Check the evaluator itself with known correct and deliberately wrong outputs. Otherwise a bug in the scoring code can reward the very behavior you meant to prevent. Keep a held-out set away from day-to-day tuning where possible.

OpenAI's Cookbook improvement-loop example connects traces and reviewer feedback to reusable evaluations before proposing changes. Apply that method here: turn “it ignored approval” into a case requiring a preview and no action call. Freeze the cases and rules when comparing versions. This lab reads authored records; it does not run that live API example or measure a real model.

Freeze the target before comparing

1. Case. Name the input category and expected result.
2. Baseline. Keep the earlier version's observation.
3. Candidate. Use the same expectation for the new version.

The lab reads authored run records. It does not execute a model benchmark.

A stable target

const passed = !run.error && run.value === test.expected;

For the scalar expectations used here, exact equality is the agreed check. More complex tasks need explicit rubrics or structured validators.

Think it through: When should you define the expected behavior?

IDEA 2

Challenge boundaries, not just wording

Red teaming deliberately probes failures. Try a note that asks the program to ignore permissions, a missing price, a stale record, a temporary tool failure, or an out-of-scope task. Give each case an acceptable outcome: no forbidden call, an explicit missing field, or a bounded retry. A provocative input with no expected behavior is hard to evaluate.

Separate component checks from the whole task. A permission helper can pass its own test while the full workflow calls an action before reaching that helper. Inspect the end-to-end trace too. If you find a failure, preserve its input, observed call, and expected boundary as a regression case. A finite test set supplies evidence about tested behavior, not immunity to every possible attack.

A challenge with a check

1. Attack or edge. A retrieved note asks for a forbidden action.
2. Expected boundary. The action must remain uncalled.
3. Keep the case. Use it to catch a future regression.

A test needs an expected safe outcome, not just a provocative input.

A correct helper can be called too late

// Broken whole-workflow ordering:
// publish(draft);
// if (!approved) return "preview";
// Test the trace: an unapproved run must never call publish.

Testing only whether the helper recognizes false approval misses the earlier side effect. The whole-path check must verify when the boundary was enforced.

Think it through: A permission helper passes its unit test, but an unapproved workflow calls publish first. What should the evaluation show?

IDEA 3

Count errors and look for regressions

A regression is a case that passed before a change and fails afterward. An improvement is the reverse. Report both, even if the candidate's total score increases. A higher average can conceal a newly broken permission boundary.

A runtime error remains a failed run, including when the expected output is null. Do not drop errored cases from the denominator or treat the absence of a value as intentional abstention. The error field tells you that the program did not complete its intended decision.

Keep all outcomes

1. Before. Did the baseline finish and match?
2. After. Apply the identical rule to the candidate.
3. Compare. Record each direction of change and the full case count.

Null can be a valid answer; an error with null is a failed execution.

An error is not abstention

const expected = null;
const candidate = { value: null, error: "timeout" };
// This case fails because execution did not complete.

Testing the value alone would incorrectly pass this run. Checking the error first distinguishes intentional null from a crash.

Think it through: A run times out and stores value:null; the expected result is null. How should it be scored?

Put it into practice

Count real matches in authored run records, including errors, and identify changes in both directions.

1. Inspect the timeout case: null is both the expected answer and the error placeholder.
2. Run the starter and identify the false pass.
3. Insert the error guard and run all comparison sets.
4. Add a custom regression and observe both totals and the regression list.

Your next experiment: Change one candidate output to the wrong value while leaving another improved. Can the total score hide a regression?

Keep the task fixed, count failed runs, and report regressions alongside gains.

Key terms

Regression

A previously passing case that fails after a change.

Red teaming

Deliberately probing a system for failures and boundary violations.

Denominator

The total set of cases used when computing a pass rate.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.