What are Experiments?
Experiments are controlled, block-level evaluations for workflow blocks. They run the same block with multiple consensus passes over the same set of documents and use agreement between those passes as the quality signal. Use experiments when you want to answer questions like:- Did this schema change make extraction fields more stable?
- Which invoice documents are causing low agreement?
- Which split category or classifier category is ambiguous?
- Did a prompt, category, or split-definition change improve the block?
Experiments vs Evals
Evals and experiments both help you keep workflow changes under control, but they answer different questions.
Use an eval when you know what the output should be. Use an experiment when you
want to find weak spots, compare block configurations, or inspect whether a
block is internally consistent before you write stricter assertions.
Supported Blocks
Experiments are currently supported for:
Other workflow blocks can still be covered with workflow evals, but they do not
currently produce experiment metrics.
How Experiments Work
An experiment is attached to one block in one workflow. It stores:- The block under test - the workflow block id and block kind.
- A fixed document set - materialized block inputs captured from completed workflow runs or from files uploaded while creating the experiment.
- A consensus count - 3, 5, or 7 independent passes.
Experiment-run metrics are normalized across the same shape for every
supported block:
This lets the dashboard show the same core views for different block types:
overall summary, by-document scores, by-target scores, and voter-level
disagreement.
Creating an Experiment
- Open a workflow in the dashboard.
- Go to Console -> Experiments.
- Click Experiment.
- Name the experiment.
- Choose the number of consensus passes: 3, 5, or 7.
- Select the block to evaluate.
- Select files from completed runs, or upload files for the experiment.
- Create the experiment.
Reading Results
The experiment detail page has three sections:
The metrics views help you move from broad signal to specific evidence:
- Summary shows the overall experiment score, target averages, document averages, and previous-run delta when available.
- By document shows which files are least stable.
- By target shows which fields, categories, subdocuments, or keys are least stable across the document set.
- Votes shows the individual candidate outputs from an experiment run for one document-target cell, including the agreed value and disagreements.
Staleness and Re-runs
Experiment metrics belong to a specific experiment run, block configuration, and document set, and are read from the experiment-run metrics API. If you edit the block or change the experiment documents, Retab marks the latest run’s metrics as stale. If the output schema changes, Retab can also report schema drift. When an experiment is stale, run it again to refresh the score against the current workflow draft. Retab keeps run history, so you can compare the latest score with earlier runs and see whether a configuration change improved or degraded the block.Recommended Workflow
- Run the workflow with representative documents.
- Create an experiment for an Extract, Split, Classifier, or split-by-key For Each block.
- Start with 3 consensus passes while iterating quickly.
- Inspect the lowest-scoring documents and targets.
- Adjust the schema, prompt, categories, or split definitions.
- Re-run the experiment and compare the score with the previous run.
- Add workflow evals for outputs that should now be protected with explicit assertions.
Using the SDK
The dashboard flow above maps onto a small set of SDK calls. The same calls back the MCP tool surface, so anything you can do interactively or through an agent you can do programmatically.Create an experiment
Pick a supported block, give the experiment a name and a document set, and choose how many consensus passes per document (3, 5, or 7). Documents come from prior workflow runs (viadocument_captures) or as explicit handle inputs.
Run the experiment
Trigger consensus runs against the current draft block config. This is async; the SDK returns a run resource that you inspect through the experiment runs API.n_consensus and document set.
Inspect the run and results
Poll the run untillifecycle.status is terminal, then read the per-document
results produced by that run.
Read metrics
Metrics live under the experiment run with four views — start atsummary, drill
into by_target on low-scoring fields, then into votes to see voter
disagreement on a specific cell. These are experiment-run metric views under
/v1/workflows/experiments/metrics?run_id={run_id}.
Metric responses use kind as the shared discriminator across successful views.
Successful payloads also echo view for compatibility. Because this endpoint is
scoped to a concrete run_id, it returns the historical metrics for that run
even if the experiment definition has since changed. Check the experiment’s
freshness / run_plan_mode fields from experiments.get or
experiments.list to decide whether to create a newer run.
experiments.get(...) and experiments.list(...) return
freshness.status: "stale" and run_plan_mode: "run". Call
runs.create(...) to recompute and then inspect the new run’s metrics. Existing
run metrics remain readable as historical evidence.
Update / delete
AsyncRetab.workflows.experiments), see the
API reference.