Skip to main content
Experiments turn a mutable Playground comparison into a named, content-addressed evaluation record. Use them when a model, prompt, tool, scorer, routing policy, or dataset change needs reproducible evidence before release.
An Experiment never follows a mutable alias. It freezes the exact inputs available at creation time and executes those values again on every rerun.

What an Experiment freezes

The snapshot is immutable and protected by database triggers. It includes:
  • every evaluation test-case input, expected output, metadata value, lifecycle field, and source reference;
  • the selected Dataset Hub version, schema, content hash, row order, row payloads, and row content hashes when a dataset version is attached;
  • baseline and candidate prompt version identifiers, prompt content hashes, full messages, and system prompts;
  • provider, model, routing profile and strategy, parameters, seed, and environment;
  • tool configuration and policy snapshots;
  • complete scorer definitions, scorer prompt hashes, and settings;
  • calibration mapping identifiers, score scales, methods, and mapping payloads;
  • evaluation execution settings, model settings, custom metrics, executor configuration, runner version, code version, and snapshot schema version.
The experiment record stores a SHA-256 hash of the canonical snapshot. Each variant has its own configuration hash. Changing a live prompt, Playground variant, dataset row, scorer, or calibration mapping after creation does not rewrite either value.
1

Prepare the matrix in Playground

Create one baseline and at least one candidate. Select the exact provider, model, tools, parameters, scorers, and policy configuration that you intend to compare.
2

Publish reusable inputs

Publish the Dataset Hub version and approve any referenced Prompt Hub version. Draft or unapproved versions are rejected when the experiment is created.
3

Promote to an Experiment

Choose Promote from Playground, name the experiment, and record the expected dataset and variant hashes. If a live asset changes before promotion completes, creation fails with a stale_asset conflict instead of silently freezing a different value.
4

Run the matrix

Select Run matrix. Every variant receives a normal evaluation run, and every row receives a normal test result. Experiment bindings preserve the exact execution, variant, run, and test-result lineage.
5

Inspect the comparison

Review paired rows, regressions, score distributions, uncertainty, cost, p50/p95 latency, failures, tool errors, policy blocks, unknown values, and evidence completeness together.
6

Record a decision

Select a candidate and write a rationale. Winner approval is blocked when the candidate violates the frozen winner policy, introduces disallowed regressions, has incomplete cost, or crosses an uncalibrated judge boundary.
7

Create a publish proposal

An accepted winner can create a proposal for a prompt version, Evals-as-Code manifest, online monitor, release artifact, signed report, or release gate. The proposal is always pending_approval; the Experiment does not make a live change.

Comparison semantics

Each candidate is paired to the baseline by frozen test-case identifier. The comparison reports: Every candidate receives one outcome:
  • improvement: pass rate or paired outcomes improve without a new paired regression;
  • regression: quality falls or the candidate introduces a paired regression;
  • tradeoff: the candidate fixes some rows and regresses others;
  • tie: complete paired quality is unchanged;
  • inconclusive: required paired data is missing or uncertainty crosses zero;
  • not_comparable: judge or calibration identities differ without a shared scale.
The Summary tab shows the decision logic used for the classification. Missing data and judge discontinuities appear as warnings; neither is converted to zero.

Experiment workspace

The detail workspace contains eight sections:
  • Summary combines headline quality, cost, latency, classification, warnings, and decision logic.
  • Variants shows the baseline and candidates with model, provider, scorer, calibration, and configuration hashes.
  • Rows is a virtualized paired matrix with baseline output, candidate output, scorer delta, cost, latency, and classification.
  • Regressions focuses on newly failing and newly fixed cases.
  • Metrics shows distributions, uncertainty, operational tradeoffs, tool failures, and policy blocks.
  • Traces links normal run, test-result, model-call, trace, and evidence identifiers.
  • Decision records the candidate, comparison hash, rationale, actor, and decision time.
  • Evidence shows publish proposals and the full frozen snapshot payload.
Row filters include regression, improvement, disagreement, unchanged, missing, high cost, tool error, policy block, and free-text category or tag search. The matrix only renders visible rows, so large datasets remain responsive without changing the comparison result.

Progress, cancellation, and reruns

Execution progress reports completed variants and processed rows. A cancellation request stops the matrix before the next variant. Completed variant bindings remain append-only evidence. Use Rerun snapshot to execute the same immutable values again. The new execution records its parent execution and increments the attempt number. Only one queued, running, or cancellation-pending execution can exist for an Experiment at a time.
Rerunning an Experiment does not refresh prompt aliases, dataset versions, scorer settings, calibration mappings, or policies. Create a new Experiment to test newer inputs.

Empty and blocked states

API reference

All endpoints are organization-scoped. UUIDs from another organization or another Experiment are rejected by composite database constraints, even when the individual identifier exists.

Idempotency

Creation, run, decision, and publish requests require an idempotency key. Replaying the same key and same request returns the existing record. Reusing a key with a different snapshot, rerun parent, winner, or target returns 409 CONFLICT.

Create an Experiment

Run and rerun

Omit parentExecutionId for the first execution. A rerun parent must be terminal and belong to the same organization and Experiment.

Approve a winner

An accepted decision requires an eligible non-baseline candidate. reject and needs_review decisions must not provide a winning variant.

Propose publication

The response contains status: "pending_approval", apply: null, the Experiment snapshot hash, winner configuration hash, comparison hash, and decision identifier.

Audit evidence

The audit log records snapshot creation, execution completion or cancellation, winner decisions, and publish proposals. Use the following identifiers when exporting evidence:
  • Experiment ID and snapshot hash;
  • Dataset version and content hash;
  • variant ID and configuration hash;
  • execution ID, attempt, and rerun parent;
  • evaluation run and test-result IDs;
  • model-call, trace, and evidence identifiers;
  • decision ID, actor, rationale, and comparison hash;
  • publication proposal ID, target, environment, and pending_approval status.
These links allow an auditor to move from the release proposal back to the exact row output and frozen input that justified it.