Strategy · 4 minute read
AI Evaluation Plan Template: Proving a System Before Launch
An AI evaluation plan defines the correctness criteria for a system's outputs, the golden dataset that represents them by category, the scoring methods for each criterion, the thresholds that gate release, the production sampling that keeps quality measured after launch, and the owners and cadence, all agreed before the system is built so acceptance is evidence rather than opinion.
An evaluation plan is the document that turns "does it work?" into a measurement. Written before the build, it defines what correct means, how it will be tested, what passes, and how quality stays measured once the system is live. This template is the plan FISTA writes with process owners at the start of every engagement. It implements the evaluation-driven development whitepaper and supports the acceptance criteria in the AI statement of work template.
What does the template contain?
| Section | Content | Owner |
|---|---|---|
| 1. System and scope | What is evaluated; case types; autonomy level | Process owner |
| 2. Correctness criteria | Per output: hard constraints, required content, format, abstention rules | Process owner + engineering |
| 3. Golden dataset design | Categories, difficulty, failure modes, adversarial cases, sizes, sourcing, verification | Engineering + process owner |
| 4. Scoring methods | Per criterion: deterministic check, retrieval metric, judge with calibration, end-state test | Engineering |
| 5. Thresholds | Per category; zero-tolerance criteria; latency and cost budgets | Process owner |
| 6. Release gates | What blocks release; who can waive; how waivers are recorded | Engineering + process owner |
| 7. Production sampling | Rate, stratification, review queue, service level, feedback to dataset | Engineering + reviewers |
| 8. Drift monitoring | Input mix, score trends, alert thresholds | Engineering |
| 9. Ownership and cadence | Roles; review dates; dataset change process | Operations leadership |
| 10. Reporting | Evidence report format for acceptance and reviews | Engineering |
How are correctness criteria written?
Per output, in language a domain expert and an engineer can both verify: what must be present, what must never appear, format and structure, tone where it matters, and when the system must abstain or escalate. Each criterion names its scoring method. "Helpful" is not a criterion; "cites the policy section that governs the answer" is.
How is the golden dataset designed?
| Dimension | Design question |
|---|---|
| Categories | Which case types exist, and how many cases per category make thresholds meaningful? |
| Difficulty | Easy, typical, hard, and edge cases per category |
| Failure modes | Known weaknesses represented explicitly |
| Adversarial | Injected instructions, missing data, out-of-scope requests |
| Sourcing | Real cases, redacted, with consent; synthetic only to fill documented gaps |
| Verification | Who confirms the expected outcome; two-person verification for consequential categories |
| Versioning | Dataset versions tied to releases |
Build guidance is in how to build a golden dataset.
Which scoring methods apply?
Deterministic checks for structure and exact values; retrieval precision and recall for grounded systems; groundedness checks claim by claim; rubric judges for subjective criteria, calibrated against human ratings with agreement published; end-state verification for agents; safety classifiers as hard gates. Judges are re-calibrated when the judge model or rubric changes; see LLM evaluation explained.
How are thresholds and gates set?
Thresholds per category are set by the process owner against the cost of errors; zero-tolerance criteria (prohibited actions, safety) block on any failure; latency and cost per task budgets are thresholds too. Gates run on every prompt, model, retrieval, tool, or configuration change. Waivers are recorded with who, why, and until when, and only the process owner can lower a threshold. The gate discipline is described in AI regression testing.
How does production sampling work?
A sampling rate stratified by category and confidence, heavier where the system is least certain; a review queue with a service level; misses triaged by the process owner as specification gap, dataset gap, model weakness, or upstream data issue; verified misses added to the dataset; and drift tracked in input mix and scores. The queue design is in how to build a human review queue.
What does the evidence report contain?
Dataset version; results by category against thresholds; zero-tolerance results; latency and cost against budgets; comparison with the previous release; production sampling results and trends; open misses and their triage; and the process owner's sign-off. The same report serves acceptance, performance reviews, and governance.
How does the plan change for agents?
Agent plans add scenarios rather than single prompts: a starting state, a request, and the expected end state, including cases where the correct behavior is to stop and escalate. Scoring adds tool-call traces (required calls made, prohibited calls absent, approvals requested where rules demand), end-state verification in a sandboxed copy of the systems the agent touches, and step and cost budgets per scenario. The harness for this is described in how to build an agent evaluation harness.
What are the common mistakes?
- Plan written after the build.
- Aggregate thresholds only.
- Judges uncalibrated.
- Dataset static after launch.
- Engineering lowering thresholds to ship.
How does FISTA Solutions help?
FISTA Solutions writes the evaluation plan with process owners before building any AI agent, delivers the harness and dataset as buyer-owned artifacts through forward deployed engineers, and installs the practice across teams through AI enablement. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.
To write the plan for your next system, message FISTA on WhatsApp, or read the AI evaluation checklist for the short-form version.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01When should the evaluation plan be written?
Before any prompt is tuned or any model chosen, alongside the specification. The plan is the definition of correct, and building before it exists means the dataset gets assembled from whatever the system happens to do well. It is signed by the process owner and versioned with the specification.
02How big should the golden dataset be?
Large enough to cover every category, difficulty level, and known failure mode with enough cases to make thresholds meaningful, and it grows from production misses. A few hundred verified cases across categories is a common starting point; coverage matters more than size, and every case needs a verified outcome.
03What thresholds should be set?
Per category, set by the process owner against the cost of errors in that category, with zero-tolerance criteria for prohibited actions and safety. Aggregate thresholds alone hide the rare category that matters most. Latency and cost per task budgets belong in the plan as thresholds too.
04What happens after launch?
Production sampling scores real outputs against the same criteria, stratified by category and confidence; misses route to the process owner for triage; verified misses join the golden dataset; drift in inputs and scores is tracked; and the results feed autonomy decisions and performance reviews on a set cadence.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.