Environments and targets
Environments say where a span came from or where an evaluation ran; targets say what is being evaluated. Both are named by the project and bound to spans, API keys and subjects.
Two settings give every measurement its coordinates. An environment says where something happened: development, staging, production, or any name the project chooses. A target says what is being measured: an application, a model configuration, a repository, a pipeline. A span names its environment; an evaluation names its subject and target; an API key can be bound to one environment so a staging collector cannot write production traces.
Status (25 October 2026). Environments and targets are in the application under Settings → Environments and Settings → Targets (requirement EV-001 is in progress in the requirements ledger and being verified now). Nothing on this page is marked verified.
Environments
A project starts with no environments; a project admin creates them under Settings → Environments with a key and a display name. The key is what spans, API keys and subjects refer to ("environment": "production" in a batch). Names and keys are the project's own; nothing is inherited from CodeBook or MadeBook.
An environment can be deleted only by typing its exact name, and the server refuses the deletion while a target or an active API key still uses it (IN_USE).
Environments on spans
Every batch names one environment. Spans in the batch inherit it. The trace explorer facets by environment, saved queries can pin one, and online scoring policies and alert rules can be limited to one. See Ingestion and The explorer.
Environments on API keys
An API key may be bound to an environment at creation. A bound key can only ingest batches for that environment; a batch naming another is refused. This is the recommended way to keep a production collector from writing to staging by accident. See API keys.
Targets
A target names a thing under evaluation so that reports, experiments and impact readings for the same thing can be found together. A project admin creates targets under Settings → Targets with a name, a kind and an environment. Deleting a target needs its exact name and is refused while something still refers to it.
Subjects are exact
A target is a label; a subject is the exact thing one evaluation ran against, and it is what a report binds to. For a repository change the subject carries the repository's full name, the commit and the base commit, an artifact-set digest and the environment; EvalBook computes a subject_digest over the canonical subject and returns it, and the report binds to that digest. A report whose subject lacks the repository name is refused. CodeBook fills the subject when a station requests an evaluation; the public API accepts the same shape. See Release gates.
Target bindings
The evaluations API lets a project bind a suite to a target (target bindings: create and revoke), so that a request naming the target runs the suite's active version. Bindings are listed with the suite; revoking one is audited. The pages for suites are not in the shell yet; see the Status note on Suites and thresholds.
Capture policy and retention are per project, not per environment
The capture policy (full, redacted, metadata only) and retention per content class apply to the whole project, whatever the environment. If production must keep less than staging, use two projects. See Redaction and capture and Retention, export and deletion.