Build a prompt set and assertions for an eval
Your eval is only as honest as the prompts you feed it and the assertions you score against. Clean prompts that look nothing like real usage hide failures. Vague assertions make two reviewers reach different scores on the same output.
Build a prompt set that looks like real usage
Start with prompts people actually type, not the ones you would ideally see.
Sources to pull from:
- research sessions and contextual interviews
- product feedback and support tickets
- usage logs and intent data
- known scenarios where output has caused incorrect action
Avoid:
- internally written prompts that sound clean
- prompts that only describe the happy path
- prompts polished to remove the messiness of real input
If your prompt set never breaks the system, it is not testing the system.
Cover both stable and stretch behavior
| Prompt type | What it tests | Signal it gives |
|---|---|---|
| Regression | Behavior the system must always get right | A drop means something broke. |
| Capability | Harder tasks the system cannot yet reliably handle | Progress over time means the system is improving. |
Without regression prompts, you cannot catch what slipped. Without capability prompts, you can only detect failure, not progress.
Vary by context, not by phrasing
Three rewordings of the same request are not three prompts. They are one.
| What changed | Counts as |
|---|---|
| Same context, different wording | One prompt type |
| Different context, such as audience, stakes, missing inputs, or conflicting sources | A new scenario |
For each scenario, write three to five prompts that vary the wording. For each new context, start a new scenario.
If every prompt in your set tests the same context, your eval coverage is narrower than it looks.
Write assertions a second reviewer would apply the same way
An assertion turns a quality requirement into a check you can verify directly from the output.
Each assertion should be:
- observable in the output, not in the system or its reasoning
- repeatable across prompts in the same scenario
- consistent across reviewers
Do: “Doesn’t assign an owner unless the source names one.”
Don’t: “Sounds professional and accurate.”
If two reviewers would score the same output differently, the assertion is too vague.
Match each assertion to the right kind of judge
| Judge type | Use for | Assertion must be |
|---|---|---|
| Automated, such as an LLM or rule | Must-pass behavior, safety, refusal, factual grounding | Answerable from the output text alone |
| Human | Felt quality, tone fit, usefulness in context | Tied to clear examples of good and weak responses |
Most eval sets need both. A judge that cannot read the signal an assertion is written for will not score it reliably.
Run three checks before you scale an assertion
| Check | Pass if | Fail if |
|---|---|---|
| Consistent | Two reviewers reach the same result. | Reviewers disagree on the same output. |
| Discriminating | The assertion separates good output from weak output. | Strong and weak responses both pass. |
| Transferable | The assertion holds on outputs it was not written from. | It only works on the examples used to draft it. |
If any check fails, fix the assertion before scaling. An assertion that fails one of these checks will not get more reliable when applied to more output.
Name what assertions cannot yet capture
Some behaviors matter to people but do not fit a current assertion, such as tone shifts, recovery after a failed turn, or follow-up usefulness.
- Write them down specifically.
- Note why the current assertion misses them.
- Share them with engineering and applied science partners.
A gap named precisely is a gap someone can solve.
Key takeaway
Prompts decide what your eval can see. Assertions decide what your eval can score. If either is off, the rest of the eval cannot recover.