Inspect results and compare runs

Use Results in Prompt Studio to reopen dataset evaluations, inspect the evidence behind a score, and compare a candidate run with a baseline. Comparison reads saved outputs and scores; it does not generate new answers. This guide continues the Support ticket triage example from Run evaluations. Start with the recorded Support triage v1 run. To compare versions, prepare a second run with matching test conditions.

Find a recorded run

1. Open Results in the Studio sidebar. Use the prompt selector to choose Support ticket triage, or All prompts to browse across prompts.
2. Filter by run status. With a prompt selected, you can also filter by version. Choose All versions to see both versions of this example; use Clear filters if the expected run is missing.
3. Open Support triage v1. Check its prompt version, model, dataset, and rules in Run overview.

The list’s Run status describes execution. Completed does not establish that the answers met your requirements. Open the run to inspect pass rate, scoring coverage, errors, and what each metric means. Use All runs to return to the list, or Switch result run to open another run. Keep the run URL to reopen the same evidence later.

Inspect a case before trusting its score

Under Test cases, search inputs and outputs or filter to Failed checks, Not fully evaluated, Generation errors, or Evaluation errors. Open the password-reset ticket: I forgot my password. How can I reset it? Read these sections in the case panel: Use Previous case and Next case to move through the current case selection. Open trace, when available, opens the linked generation request. Provider-backed rule results can also link to their scoring requests. In the recorded baseline, the password-reset ticket received low priority, while its reference says normal. The required Support ticket contains JSON rule passed because the response contains JSON. Read the reason and the answer together.

Distinguish a failed check from missing evidence

Generation and evaluation have separate states. An answer can exist while scoring is still running or has encountered an error. A provider failure or skipped rule is not a failed quality check. Expand Run details to identify the saved dataset and rule snapshots, sampling seed, selected prompt version, and original estimate. Later edits to the dataset or rule library do not rewrite this evidence. Older runs without saved case snapshots expose the records still available and cannot be used for this comparison workflow.

Prepare a comparable candidate

For this example, keep the dataset, selected cases, model, API key, and rule settings unchanged. Change the prompt version so you can inspect the effect of a specific instruction.

Create the support-ticket v2 run

1. Open version 1 in Build and click New draft. Describe the change as Clarify that individual password-reset requests have normal priority.
2. In the new draft’s System message, add this sentence after the priority rule:
   Priority clarification

   Password-reset requests are account issues with
   normal priority unless service-wide or multi-user
   blocking is stated; they are not low-priority
   general questions.
   
3. Click Save changes, then Run on dataset. Select the same API key and model as Support triage v1.
4. Reuse the unchanged Support ticket triage dataset with all eight cases. Select the same required Support ticket contains JSON rule, or the saved Support ticket checks rule set with those settings.
5. Name the run Support triage v2, reuse sampling seed 42, and preview and launch the evaluation within your chosen spend cap. The recorded example used $0.10; check the estimate for your setup.

Wait for completion before comparing. The example’s v2 version becomes read-only after evaluation. If your prompt already has more versions, use the version number created by your own New draft action.

Selecting the same percentage does not ensure the same sampled cases. Reuse the same seed with unchanged dataset content, or use 100% as this example does. An unchanged dataset can reuse its saved snapshot.

Compare the candidate with its baseline

Understand the comparison labels

Advisory scores do not change these labels. The comparison counts required-check outcomes, not text differences or changes in cost. Use Switch result run or View baseline results to inspect each run’s recorded metrics and detailed rule evidence.

Inspect the password-reset change

In the recorded comparison, the baseline says low priority and the candidate says normal, matching the reference. The row is still Unchanged: both outputs passed the JSON-content rule. The comparison reports zero automatic improvements because that rule does not measure priority correctness. Changes and missing scores is empty for this pair; choose All cases to inspect the different answers. Review output differences even when every row is Unchanged. To measure classification quality automatically, add a rule with appropriate evaluation criteria, test it, and evaluate both versions under the same new rule settings. The run URL reopens the recorded run. Choose the baseline again after reloading; the baseline selection is not stored in that URL.

Send an output for human review

When a generated answer needs a person’s decision, return to Test cases, open it, and expand Send for human review. Choose Review priority and click Send to review. Studio opens the queued review item in Review. This action is available for a completed generated case with a recorded execution. Review priority controls the queue item’s urgency; it is separate from the priority field produced by the support-ticket prompt. Follow Human review to claim the case, record independent decisions, resolve disagreements, and reuse a final correction.

Troubleshooting

After reviewing the candidate’s evidence, follow Versioning and releases to check the prompt’s publication requirements. Keep the baseline and candidate runs available for any release checks that need them.