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.
Recommended workflow
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.
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.
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.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 returns409 CONFLICT.
Create an Experiment
Run and rerun
parentExecutionId for the first execution. A rerun parent must be terminal and belong to the same organization and Experiment.
Approve a winner
reject and needs_review decisions must not provide a winning variant.
Propose publication
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_approvalstatus.