> ## Documentation Index
> Fetch the complete documentation index at: https://braintrust.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Experiments

> Choose how to run evaluations, in code, the UI, or CI/CD, and turn each run into a permanent record you can compare and share.

An experiment is an immutable snapshot of an evaluation run: permanently stored, comparable over time, and shareable across your team. Unlike playground runs, which overwrite previous results for fast iteration, experiments preserve exact results so you can measure improvements, catch regressions, and build confidence in your changes.

## Create an experiment

Choose the approach that fits your workflow. Each one produces the same kind of experiment, comparable to any other in your project.

* **[Run in code](/docs/evaluate/run-in-code)** with the SDK. The most flexible path, with full control over your task, data, and scorers, and the one to use when you want evals versioned alongside your application.
* **[Run in the UI](/docs/evaluate/run-in-ui)**, without writing code, from an existing dataset or by promoting a playground run.
* **[Run in CI/CD](/docs/evaluate/run-in-ci)**, to catch regressions automatically on every pull request.

For advanced SDK techniques like trials, hill climbing, attachments, and tracing, see [Advanced eval techniques](/docs/evaluate/advanced-evaluations).

## Analyze results

Once an experiment finishes, dig into the results:

* [Interpret results](/docs/evaluate/interpret-results) to read the experiment table and drill into individual traces.
* [Compare experiments](/docs/evaluate/compare-experiments) to measure improvements and regressions between runs.

## Next steps

* [Run experiments in code](/docs/evaluate/run-in-code) with the SDK
* [Write scorers](/docs/evaluate/write-scorers) to measure quality
* [Build datasets](/docs/annotate/datasets) to power your evaluations
* [Evaluation best practices](/docs/evaluate/best-practices) for reliable, high-signal evals