What to check in an eval suite: the seven things that matter

A suite is better when it protects the things that would cause harm. Here are the seven classes we work through, in the order we usually add them.

1. Behaviour, at the level a caller sees it

The first class. For each significant flow, assert what a user or a calling system gets back for a valid request. Drive it through the same entry point the real caller uses, rather than through internal functions, so the check stays true through a refactor.

This is the least glamorous class and it catches the most, because it is what most changes accidentally alter.

2. Contracts at the boundary

Anywhere your code passes something to a system that did not build it: an API response shape, an event payload, a database schema, a file format, a webhook. These deserve explicit checks that assert the required fields exist, the types are what they claim, and nothing that used to be there disappeared without notice.

Boundary breakage is the most expensive kind, because the failure appears in someone else's system, hours later, in a way nobody can trace back to a diff. A schema assertion in your suite turns that into a failed build in the pull request that caused it.

3. Unusual cases and error paths

Normal use is the part that always works, because it is the part everyone tries. The value is in the rest: empty collections, missing optional fields, boundary numbers, duplicate submissions, expired tokens, a dependency returning an error, the same request arriving twice.

Anthropic's eval design guidance lists exactly this category for model evals and the same list applies to code: irrelevant or nonexistent input, over-long input, badly formed input, and cases ambiguous enough that a human would hesitate [1]. Generated code is particularly weak here, since the training signal is full of examples that handle the normal case and stop.

Also assert the error behaviour itself. Check that a bad request is refused with the right status, without leaking internal detail, and without a partial write left behind.

4. Permissions and tenancy

The class most often missing and most damaging when it fails. For every resource, assert who can read it, who can write it, and what happens to someone who should not be able to do either. If your product has organisations, teams, or tenants, assert that data from one cannot be reached from another, including through search, exports, aggregate counts, and error messages.

Write the negative cases explicitly. A check that an authorised user succeeds is worth much less than a check that an unauthorised one fails, and the second is the one nobody writes.

5. Data invariants and migrations

Things that must remain true about your stored data whatever the code does. A balance never goes negative. A record always has an owner. A soft-deleted row never appears in a list. Two rows never claim the same unique slot. Statuses only move in permitted directions.

Migrations deserve their own check: run the migration against a copy of data with the same structure as production, then assert the invariants still hold and the row counts match expectations. A migration is the change class where a mistake is hardest to undo, which makes it the one most worth blocking with a check.

6. Security-relevant paths

Give the common flaw classes their own explicit checks rather than trusting that they were handled. Injection at every place a string becomes a query or a command. Output escaping wherever user text is rendered. Authentication on every endpoint that should have it, asserted by testing that the unauthenticated call is refused. Secrets absent from logs and error responses.

The reason to be explicit is measurable. Veracode's spring 2026 testing across more than 150 models found only 55 percent of generations produced secure code, with Java at 29 percent and cross-site scripting handled correctly in roughly 13 to 15 percent of relevant cases, while syntax correctness ran above 95 percent [2]. That difference has stayed the same for two years. Generated code will compile and will not necessarily be safe, so safety needs its own assertions.

7. Performance thresholds where they are part of the promise

Not micro-benchmarks. Hard thresholds on the paths where slowness is a defect: the query that runs on every page load, the export that has to finish inside a request timeout, the job that must complete before the next one starts. Assert the number of queries too, since the most common performance regression in generated code is a loop that issues one query per row without anyone noticing.

What not to bother automating

Three things, and being deliberate about this is what keeps a suite trusted.

Anything cosmetic that changes weekly. Exact copy, exact spacing, exact colour. Assert that a required element is present and reachable, rather than that a heading reads exactly one way; otherwise the suite becomes a cost on ordinary design work.

Implementation detail. How many times a private method was called, whether a particular class exists, the internal order of operations. These break on refactors and teach the team that failures mean nothing.

Anything you cannot make deterministic without a lot of work. A check that fails one run in twenty is worse than no check, because it trains everyone to run it again and it devalues every other check. Either fix it or take it out of the blocking suite. When evals give false confidence covers this in full.

How to sequence it

Two or three classes on day one, chosen by what would cause the most harm: usually behaviour on your main flow, plus permissions if you have multiple tenants, plus data invariants if you handle money. Add the rest as the product and its failures show you where the risk actually is.

For a codebase that already exists with none of this, the staged approach is in adding evals to an existing codebase. For what the checks are worth in business terms, see the business case for evals.