The eval set is the spec. An AI PRD that ships without test cases is a 2018-shape document — a feature list the team will silently reinterpret on every code review. The position is blunt: if your AI PRD does not include a 10–30 case eval set, a per-task rubric, and a pass-rate threshold on day one, you have not written an AI PRD. You have written a SaaS PRD with the word “AI” added.
This is a spoke under the idea validation playbook within the idea-to-product manifesto. The playbook describes the 1–2 week sequence; this article argues why the eval set is the load-bearing artifact in it.
Table of Contents
- Why feature-list PRDs break for AI
- What an eval-first PRD contains
- The 4-step authoring process
- Worked example — with vs without evals
- The handoff signal
- Frequently Asked Questions
- Closing
Why feature-list PRDs break for AI
A 2018 SaaS PRD encoded determinism. “When the user clicks Save, the row is persisted” is a single assertion the implementation either satisfies or does not. The PRD’s load-bearing section was the user-story tree; acceptance criteria were checkboxes; the eval set was an afterthought called QA.
A 2026 AI PRD cannot encode determinism. “When the user clicks Triage, the agent labels the email correctly” is not one assertion — correctly is a distribution. The same prompt, same model, and same input produce different outputs across runs. Anthropic’s Building Effective Agents treats this as a first-order property of agent systems: success criteria must be measurable, not asserted.
Three facts force the structural change.
AI outputs are probabilistic. Quality is a rate, not a state. A PRD line that says “the agent classifies emails into priority buckets” is silent on what 80% accuracy means versus 95% — and that 15-point gap separates a usable product from one nobody trusts.
The model layer updates outside the team’s control. The current state-of-the-art mix tracked by the Artificial Analysis leaderboard includes Gemini 2.5 Pro, GPT-5, and Claude Opus 4.8 — none of which existed when many in-flight PRDs were authored. A spec that does not encode an eval threshold cannot detect when a vendor model update silently shifts behavior overnight.
The pilot-to-production gap is the dominant failure mode. McKinsey’s State of AI reports 78% organizational adoption but a small fraction capturing material value. The common cause: teams ship at a quality bar nobody signed off on, the product underperforms in production, and there is no falsifiable rollback criterion in the spec.
A feature-list PRD cannot fix any of these. The eval set is the only artifact that survives a model swap, a prompt rewrite, or a vendor swap. Everything else is decoration.
What an eval-first PRD contains
An eval-first PRD is not a different document — it is the same document with one additional section that the rest of the spec is graded against. Concretely, the eval-first PRD adds:
A named eval set of 10–30 representative inputs. Not random inputs. The hardest inputs the system will face in the first 90 days of production — the edge cases the founder already worries about. 10 cases is the floor for distinguishing a regression from a flake; 30 is the ceiling before code is written. The eval set grows during the build, but it must exist at PRD time.
A 3-line rubric per task. A rubric is the grading instruction a human reviewer or LLM-as-judge uses to score one output. Three lines is the discipline: one for pass, one for fail, one for the boundary case. Longer rubrics are usually two rubrics conflated into one.
A pass-rate threshold. A single number per task — for example, 85% pass on the eval set. The threshold is the falsifiable definition of “shipped.” Without it, “good enough” is a conversation the founder loses to a vendor at every milestone review.
A per-task failure-mode budget. For each task, what fraction of failures of which type are acceptable. A priority-classification task might tolerate 10% under-priority errors (a P3 labeled P4) but 0% over-priority errors (a P4 labeled P1, which spams the user’s inbox).
These four additions turn the PRD from a story document into a contract. The implementation team can no longer ship “the feature” — they ship a system whose behavior on the eval crosses the threshold.
For the full 10-section anatomy of the document this slots into, see the AI PRD explained. For the engineering-side perspective on how evals drive the build itself, see the eval-first build playbook.
The 4-step authoring process
The authoring process is sequential. Each step depends on the one before. A founder or PM can complete it in an afternoon for a focused feature, or across a week for a multi-task agent.
Step 1 — Pick the task
A task is one capability the AI is responsible for. Not a feature. A feature can have multiple tasks; a task is atomic.
Task: classify an inbound email into a 1–5 priority bucket given the email content plus the user’s last 30 days of reply patterns.
If the task description includes “and” describing a second output, split it into two tasks. Each gets its own eval set, rubric, and threshold.
Step 2 — Write 10–30 hard inputs
Hard inputs are the cases the founder already worries about. Not synthetic ones. Real inputs the founder either has in hand or can reconstruct from memory of the workflow.
For an email triage task, hard inputs include:
- A vendor invoice that looks like a sales pitch
- A reply-all thread where the last message is irrelevant to the original
- A short message from the user’s largest client that the model might mis-rank as low priority because it is short
- A scheduling email that requires reading a date in a non-US format
- A bilingual email where the priority signal is in the second language
The pattern is consistent across domains: list the cases that will embarrass the team if the system gets them wrong on day one. If the team cannot name ten such cases, it does not yet understand the task well enough to spec it.
Step 3 — Write the rubric
The rubric grades one output against one input. Three lines.
Pass: the assigned priority bucket is within one level of the human-labeled ground truth, AND the rationale references at least one relevant signal from the email body. Fail: the assigned bucket is two or more levels off, OR the rationale references a signal not present in the email. Boundary: when the bucket is exactly one level off in the under-priority direction (a P3 labeled P4), the case passes; in the over-priority direction (a P4 labeled P3), it fails.
The asymmetry in the boundary line is doing work. Under-priority errors are recoverable (the user finds the email later); over-priority errors are not (the user opens a junk email expecting urgency). A rubric without an asymmetric boundary has usually not been tested against a real workflow.
Step 4 — Set the threshold
A single number per task. The threshold is set before code is written, then validated against a feasibility probe (see the AI feasibility check).
Threshold: 85% pass on the eval set, measured on Claude Opus 4.8 with a temperature of 0.
A real threshold has three properties. It names the metric (pass rate). It names the model (the eval is reproducible). It is a number a non-engineer founder can defend in a stakeholder review. “85% on the eval” is defensible. “Production-grade quality” is not.
Worked example — with vs without evals
Same idea, two specs. The build paths diverge inside week one.
Idea: an AI assistant that drafts replies to inbound investor emails for a solo non-technical founder, matching her existing voice and preserving factual claims she has previously made about the company.
PRD A — feature-list (without evals)
The assistant generates a draft reply to each inbound investor email. The draft matches the founder’s voice (warm, concise, slightly self-deprecating) and avoids contradicting any factual claim from the founder’s last 90 days of sent mail. Acceptance: the founder reports 80%+ drafts as “usable with minor edits” in a two-week pilot.
This is the document a 2018 PRD author writes when an LLM is the implementation tool. The one acceptance criterion — “founder reports 80%+ as usable” — is one the founder cannot grade reproducibly, cannot test against a model swap, and cannot use to hold a vendor accountable. “Matches the founder’s voice” has no falsifiable definition.
PRD B — eval-first (with evals)
Task: generate a draft reply to one inbound investor email given the email plus the founder’s last 90 days of sent mail. Eval set: 18 representative inbound emails — 4 fundraising-update requests, 3 introduction asks, 3 declines, 2 follow-ups on previously stated numbers, 3 scheduling, 3 thank-yous. Rubric (3 lines):
- Pass: factual claims are consistent with the last 90 days of sent mail AND the draft is under 110 words AND the opening line uses one of four founder phrasings tagged in the corpus.
- Fail: the draft contradicts a prior factual claim OR exceeds 150 words OR opens with a phrase on the “avoid” list (corporate-speak openers).
- Boundary: drafts between 110 and 150 words pass only when the founder’s matching pre-existing emails are also in that band. Threshold: 80% pass on the 18-case eval, measured on Claude Opus 4.8, temperature 0.3. Failure-mode budget: factual contradictions ≤ 0%; opener-list violations ≤ 10%; length violations ≤ 15%.
The build paths diverge in the first three days. The team building PRD A spends week one prompt-tuning against the founder’s intuition. The team building PRD B runs the 18-case eval on day one, identifies the opener-list constraint as binding, and redirects effort toward in-context examples of opener style. PRD B is not longer — it is more specific where it matters and shorter everywhere else.
The handoff signal
One sentence distinguishes a PRD an implementation team can ship to from one they cannot.
If the team cannot run your eval, they cannot ship to your spec.
“Run your eval” is concrete. The team receives the eval set, the rubric, and the threshold; they execute the eval against a candidate model on day one; they report a baseline number. If the eval cannot be run — vague cases, unmeasurable rubric, missing threshold — the team will silently substitute its own definition of “done,” and the founder will discover the substitution at milestone review.
A vendor’s response to an eval-first PRD is itself a signal. A vendor who responds with “this is more rigorous than we are used to” has been allowed to grade their own homework on prior engagements. A vendor who responds with “here is our baseline on your eval after one day” can be held to the spec.
This is the same argument stop paying AI agencies for documentation makes from the procurement side: pay for the eval threshold passed, not the document written.
Frequently Asked Questions
How small can the eval set be on day one? Ten cases is the floor. Below ten, the variance in a 70%–90% pass rate is too high to distinguish a real regression from a flake. The eval grows during the build to 50–150 cases before production, but it must exist at PRD time so the team can run a baseline on day one.
Who writes the eval cases — the founder or the implementation team? The founder. The implementation team can shape the rubric and the threshold, but the eval cases come from domain knowledge only the founder has. A team writing its own eval cases is grading its own homework, and the resulting threshold is unfalsifiable.
What if the founder does not know what “hard cases” look like yet? That is the signal the idea is not yet ready for build. The 4-step authoring process is a forcing function — if the founder cannot list ten hard inputs, the founder does not yet understand the task well enough to scope it. Spend a week in the workflow with a notebook, then return to step two.
Does the rubric need to be machine-runnable, or can a human grade? Human grading is acceptable for the first eval pass. The rubric must be specific enough that two independent human graders score the same output the same way on at least 9 of 10 cases. Once stable, an LLM-as-judge can grade subsequent runs reproducibly.
How does the threshold get set if no model has been chosen yet? Set it in the abstract first (“the product is usable if it passes 80% of these cases”), then validate against a feasibility probe — running the eval against a candidate model with a baseline prompt. If the baseline returns 30%, the task is too hard for the current model layer and the spec returns to the drawing board.
What goes in the failure-mode budget? The acceptable rate of each kind of error, per task. A priority-classification task might tolerate under-priority errors but not over-priority ones; a reply-drafting task might tolerate length violations but not factual contradictions. The budget makes the asymmetric cost of different errors explicit.
Does this PRD format work for non-LLM AI systems? Yes. The argument generalizes to any probabilistic system — classification, retrieval, recommendation. The eval set, rubric, and threshold are the falsifiable contract regardless of model architecture.
How does the eval-first PRD interact with the SOW? The SOW points at the PRD; the PRD defines what “delivered” means via the eval threshold. A SOW with no attached eval-first PRD is one the vendor can interpret loosely and the founder cannot enforce. Milestone billing should tie payment to eval threshold passed, not to documents shipped.
What is the most common authoring mistake? Writing the rubric to fit the model’s current behavior rather than the founder’s quality bar. If the rubric is set after the team has been prompt-tuning for a week, it will encode the team’s compromises. The rubric must be written before implementation begins.
Closing
The eval set is the spec. A PRD whose load-bearing section is a feature list will be silently reinterpreted by the implementation team into a thousand small judgment calls, and the founder will discover the cumulative drift at milestone three, when rollback cost is highest.
The four additions are not optional polish. They are the minimum a 2026 AI PRD must contain to be falsifiable: a 10–30 case eval set, a 3-line per-task rubric, a pass-rate threshold, and a per-task failure-mode budget.
If you are about to commission an AI build and the spec on the table is a feature list, send it back with one sentence: add the eval set, or I cannot grade what you ship me.
Get the AI MVP scoping worksheet — a one-page template for the eval set, rubric, and threshold a founder can take into a vendor conversation tomorrow.
Dirk Jan van Veen, PhD
