Shipping AI and hoping for the best.
Most AI teams treated quality as something you discover in production. A prompt changes, a model updates, a feature ships, and whether any of it was actually better gets answered by user complaints and support tickets. The root problem is that "good" for AI output is a judgment call, and without a fixed definition, that judgment changes every time a different person makes it.
Evaluation turns that judgment into a measurement. You define what "good" means once, as an eval template, and the platform applies it to every response the same way, every time. The score is repeatable. The bar is fixed. And when the bar is fixed, you can actually track whether you're getting better.
The goal was to make "is this good?" a question with a consistent answer, regardless of who's asking, on what dataset, on which day.
Four ways teams were flying blind.
Sessions with the teams already running ad hoc QA on their own AI features surfaced four patterns that shaped every design decision that followed.
Teams reviewed a few outputs before a release and called it QA. The outputs they picked were almost always the ones they expected to be fine: confirming beliefs, not finding gaps.
A prompt change that improved tone often degraded factual accuracy. Without consistent measurement, these trade-offs were invisible until users noticed them.
"This sounds better" was the most common basis for a deployment decision. Without the same eval applied to both versions, "sounds better" couldn’t be trusted.
Even where teams ran evals, if the score seemed wrong there was no mechanism to say so, record it, or use that disagreement to improve the evaluator itself.
What evaluation had to be.
The four gaps from discovery mapped directly onto four design goals, each one answering a different question a team would ask about an eval.
Choose an eval type: filter down to what you actually need.
The evaluation library opens with everything visible.
The eval detail: four tabs, everything you need to know and do.
Clicking any eval in the library opens a full detail page.
Details, for understanding: instruction, variables, output type.
Usage, for observing: every run, across every project.
Feedback, for improving: disagreement as a retuning signal.
Ground Truth, for anchoring: reference examples to test against.
Eval details tab: instruction, variables, output type, error localization.
The Eval Details tab is the source of truth for what an evaluator actually does. Teams should be able to read this tab and know exactly what's being measured, what inputs it needs, what it returns, and whether it will point to the specific part of the response that caused a failure, before running a single row.
- ·The instruction is the eval: for LLM-as-Judge templates, the instruction shown on this tab is the actual prompt sent to the evaluator model, not a paraphrase, not documentation.
- ·Variables are explicit, and error localization is inline: every input the eval needs is shown as a chip, like {{output}} or {{context}}, not buried in documentation. Teams already know what’s expected when they go to map columns.
Test evaluation: four ways to supply your own data.
Before wiring an eval into a production pipeline, teams need to try it on real data. The Test Evaluation panel supports four input modes depending on where the team's data lives: a saved dataset, live traces from an Observe project, a simulation run, or typed JSON for quick one-off tests.
Select a dataset, preview a row, and map columns to eval variables. Mismatches are auto-matched where names align and flagged where they don’t.
Select an Observe project and map span attributes to eval variables. Runs against real traces from production, not synthetic data.
Identical to Tracing, but the source is a simulation run rather than live production traces.
Type the variables directly as a JSON object: no file, no column mapping.
Test results: score, reason, and exactly what failed.
After running a test, the result screen shows everything needed to decide whether this eval is the right one for the job: the verdict, the score against the threshold, the plain-language reason, and (if error localization is on) the exact phrase that caused the failure. The result isn't an endpoint; it's the beginning of an iteration.
- ·The reason is the product: engineering teams consistently said the reason was more valuable than the score. "Score: 2/5" signals something went wrong; "the response introduces a warehouse location not in the context" is a specific fix.
- ·Error localization is inline: the specific failing phrase is highlighted directly in the result text, not listed separately below.
- ·From result to action: "Add to dataset" and "Add feedback" live on every result card. The result is never a dead end.
Usage tab: see everywhere this eval is running, and how it's doing.
Once an eval is deployed across projects, teams need visibility into how it's performing across all of them, not just in aggregate, but run by run. The Usage tab shows the eval's health across time, project by project, with individual log entries that let teams drill into any result and read the full input, output, and explanation.
- ·Time filters for different alert levels: "30 min" is for live incident investigation, "Today" for daily standups, "30 days" for trend analysis, "All time" for audit.
- ·Per-project log entries, not just aggregate: the log shows which project triggered each run, what surface it came from, and the individual score. One project’s performance never gets averaged into another’s.
- ·Full context in every log entry: clicking any row expands the full run detail (input, output, context, explanation), with no need to go back to a separate tool.
Feedback & retune: when the eval gets it wrong, say so.
No evaluator is perfect. Sometimes the score doesn't match human judgment. Feedback Insight captures that disagreement formally: the team records the correct value, explains their reasoning, and submits it. That feedback feeds directly into retuning the evaluator.
- ·Recalculate vs. Retune: Recalculate reruns the current evaluator on the same input without changing it, useful if the run failed due to a transient error. Retune incorporates the feedback signal into the evaluator model itself.
- ·Correct value is a selector, not a text field: teams pick the score they believe is correct from the same scale the eval uses, keeping feedback machine-readable as a training signal.
- ·Feedback closes the loop: without it, human disagreement with an eval result had nowhere to go. It got absorbed into informal Slack messages or ignored entirely.
What designing evaluation taught me about trust.
The hardest design problem in Evaluation wasn't the library, the type system, or the CI/CD integration. It was the feedback loop. For a team to use an eval consistently, they have to trust it. Trust is earned by the system being right often enough that when it's wrong, the team notices and corrects it, not by the system being infallible.
Feedback Insight was initially resisted internally. The concern was that surfacing "the eval got this wrong" too prominently would undermine confidence in the whole evaluation system. The opposite turned out to be true. Teams that could see their feedback being incorporated, that watched past runs recalculate and align better with their own judgment, trusted the eval far more than teams that had no channel to push back on it.
The three things I'd do differently: build the four test modes as a first-class entry point, not a panel on the detail page. Surface the usage tab data as a summary on the library card, so teams don't have to open the detail page to see an eval failing in production. And add a "recommended for your use case" section to the library, seeded from the team's connected projects. Browsing 70 templates is unnecessary friction when the right five are predictable from context.