
Evaluation anatomy
Every useful evaluation has five parts:
If an evaluator result does not lead to a decision, it is still evidence, but it is not yet an operational quality gate.
Evaluator types
Prefer deterministic evaluators for exact rules. Use LLM-based evaluators when the criterion requires judgment, then calibrate them with known passing and failing examples.
Where evaluators run

Draft evaluators created during an Improve cycle should be reviewed before they become trusted release gates.
Online and offline evaluation
The strongest loop is: online failure -> log evidence -> dataset row -> evaluator -> offline release gate -> deployment -> online watch.
Create useful evaluators
1
Start from a failure mode
Use a Behavior, failing log, customer report, or product requirement to define what should pass or fail.
2
Choose the evaluator type
Use deterministic evaluators for exact rules and LLM-as-a-Judge for qualitative criteria.
3
Attach it to the prompt
Link the evaluator where it should run so evaluations and Improve cycles can use it.
4
Validate against examples
Run it against known passing and failing cases before relying on it for approval decisions.
Coverage checklist
For important prompts, cover the risks customers would notice:
Coverage does not need to be large to be useful. A small dataset with clear evaluators beats a large dataset with vague scoring.
Evaluator types
Choose the right evaluator for quality, schema, cost, latency, and custom rules.
Online and offline evaluation
Connect curated datasets, production scoring, release gates, and Improve.
Create useful evaluators
Turn product requirements and production failures into repeatable checks.
Evaluate prompts
Run prompt evaluations against datasets and review results.
Datasets
Store the cases evaluators should score.