I do not want an AI feature to reach broad traffic because the demo felt good twice. That is how teams ship a support bot that sounds confident while dropping refunds, a search assistant that hides the best result, or an onboarding helper that teaches the wrong workflow. The smallest useful fix is not a giant evaluation platform. It is a release gate that says what must be measured before the next rollout step.
The gate I would add
For a normal product team, I would treat evals like a launch readiness artifact, not a research project. The gate lives beside the release note, feature flag, and rollback plan. It answers one question: what evidence says this AI behavior is good enough for the next slice of users?
That keeps it separate from the engineering harness. I still want the harness. I wrote earlier that a small, honest eval harness beats vibes, and I still think that is the base layer. The product-delivery step is different. It decides whether the measured behavior is acceptable for customers, support, revenue, and trust.
Vercel frames evals as tests for systems whose outputs are not perfectly deterministic. That framing matters. You are not proving the feature can never fail. You are proving the current prompt, model, retrieval path, and product boundary are less risky than the status quo for a named audience.
The pass criteria should fit on one screen
I like a short gate because long gates become decoration. The release owner should be able to paste this into an issue and get a real decision.
| Question | Pass condition | Owner |
|---|---|---|
| What user task is covered? | One narrow workflow, written in customer language | PM |
| What dataset represents it? | 30 to 100 real or realistic cases, reviewed by support or domain owner | PM plus support |
| What scorers apply? | At least one deterministic scorer and one judgment scorer where needed | Engineer |
| What fails the launch? | Named thresholds for correctness, refusal, latency, and cost | PM plus engineer |
| What happens after failure? | Flag rollback, prompt revert, or user-facing fallback is ready | Engineer |
| What remains manual? | Any high-impact decision keeps human review | Product owner |
This is intentionally boring. OpenAI's grader API includes string checks, text similarity, model-scored graders, label graders, and multi-grader composition. LangSmith and Braintrust both give teams experiment records over datasets. None of that removes the need for a product owner to say which mistake is actually unacceptable.
Keep the dataset small and owned
The first dataset should not be a warehouse project. It should be a living checklist of cases the team understands. If the feature classifies support tickets, include billing, account, abuse, refund, and edge-language examples. If it drafts sales follow-ups, include the awkward cases: missing context, a customer objection, a competitor mention, and a request the model should decline.
LangSmith's evaluation workflow starts with an application target, a dataset, evaluators, and an experiment. Braintrust treats experiments as immutable snapshots that can be compared over time and run in CI. Those are useful product primitives because they let a team compare one proposed launch against the last accepted behavior.
The lazy version is a spreadsheet exported to JSONL, reviewed every Friday. Add a richer dataset workflow only when ownership becomes the bottleneck. I would rather have 60 cases the team trusts than 2,000 generated cases nobody reads.
Separate scorer confidence from launch confidence
An eval score is not a launch decision. It is evidence inside one.
OpenAI's GDPval work is a good reminder here. The benchmark uses expert preference judgments and rubrics, and treats automated grading as useful but not a replacement for expert review. That maps cleanly to product launches. A model grader can catch many regressions. It cannot tell you whether a wrong answer will create a support escalation, breach a policy promise, or confuse a buyer at the worst point in the funnel.
For launch decisions, I want three buckets:
- Deterministic checks: schema validity, required citation presence, no forbidden action, no empty response.
- Model or rubric checks: helpfulness, groundedness, tone, classification quality, escalation judgment.
- Human checks: top failures, high-impact examples, and any case where the product promise is ambiguous.
The first bucket can block a PR. The second can block a rollout step. The third should block broad launch until someone accountable signs off.
Make the gate part of rollout, not a one-time ceremony
The eval gate should sit before each traffic expansion. Run a smoke set before merge, a fuller set before internal dogfood, and the accepted suite before the first external cohort. After launch, sample real traces into the dataset whenever support, sales, or analytics finds a surprising failure.
This pairs well with the rollout ladder for feature-flagged launches. A feature flag controls blast radius. The eval gate controls whether the team has earned the next radius.
I would write the rule this way:
No AI feature moves to a larger audience unless the latest eval run is attached to the rollout issue, its failures are triaged, and the owner can name the rollback path.
That rule is small enough to enforce and specific enough to stop hand-waving. It also leaves room for judgment. A feature can ship with known failures when the audience is small, the fallback is clear, and the product owner accepts the tradeoff. It should not ship because the team ran out of patience.
What I would not build yet
I would not start with a custom eval service. The available tools already cover the important primitives: datasets, experiment history, scorers, CI runs, traces, and model comparison. The product problem is usually weaker than the tooling problem: unclear ownership, no failure budget, and no decision record.
The next useful step is to make eval runs visible in the same place launch decisions happen. If that is GitHub, attach the experiment URL and thresholds to the rollout issue. If it is Linear, make the eval result a required field before moving to the next status. If it is a release doc, put the latest run next to the rollback plan and support notes.
The forward-looking bet is simple: AI product teams will stop arguing about whether a demo looked good and start arguing about which failure budget they are willing to own. That is a healthier argument. It turns AI launch readiness into evidence, accountability, and reversible steps instead of taste.