---
id: improve.candidates-frontier
title: Candidates and the Current Frontier
summary: Interpret candidate stages, canonical receipts, constraints, retained Candidate Systems, and the current frontier.
kind: reference
product_area: improve
status: stable
updated: 2026-09-07
canonical: /docs/improve/candidates-and-frontier
---

# Candidates and the Current Frontier

## Definition

An Improve candidate moves through `working`, `focused_evaluated`, `canonical_evaluated`, `retained`, `rejected`, or `incomparable`. Stage describes evidence maturity, not source quality or recency.

## Fields, states, or lifecycle rules

Candidate stage, Harness Version, Benchmark Version, canonical Run, provenance, scores, constraint results, parent branch, and receipts form the durable evidence record. Frontier membership is a retained evidence decision rather than another candidate stage.

## Candidate System requirements

A retained Candidate System identifies an exact saved Harness Version, immutable Benchmark Version, canonical Run, provenance, scores, and constraint results. Focused evaluation can route exploration, but only canonical evaluation against the pinned cohort supports frontier retention.

A rejected candidate remains useful evidence when it reveals a regression or failed hypothesis. An incomparable candidate lacks the common evidence boundary needed for a valid decision. Do not fill that gap with aggregate intuition.

Candidate Exploration evidence is scoped to the session and branch that produced it. It is not automatically the project's global best candidate. The current frontier contains retained candidates supported by the latest valid Goal and receipts, but “current” does not mean newest or highest aggregate score.

## Harness materialization boundary

The active Improve model does not require a separate legacy “Save candidate as Harness” action. A candidate eligible for retention already references an immutable saved Harness Version. Use Assets → Harnesses to inspect that Version or select it directly in a future Benchmark Evaluation launch.

If an external worker returns only a patch, prose, or private claim, the candidate is not yet a Candidate System. Materialize the return through the supported contract so the saved Version and evaluation request become observable.

## Retention checklist

- Exact Harness and Benchmark Versions are present.
- The canonical Run is complete enough for the measurement bindings.
- Hard constraints pass; soft-constraint tradeoffs are visible.
- Evaluation receipts and hashes resolve to the claimed Case cohort.
- Parent branch and source provenance are recorded.
- The candidate is retained for evidence, not merely because it is latest.

{% example-demo title="Example: aggregate winner outside the frontier" %}
A new candidate has the highest overall pass rate but violates a hard required-Policy constraint. Its canonical receipt remains visible, but the candidate is rejected and does not displace two lower-scoring retained candidates that satisfy the confirmed Goal.
{% /example-demo %}

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Start an Improvement Session](/docs/improve/start-improvement-session)
- [Compare Harness Versions](/docs/benchmark-evaluations/compare)
{% /related-card-grid %}

## Source confidence

Code-backed: the active session contract, archive view, and coordinator evidence define candidate stages, exact identities, canonical receipts, retention, rejection, incomparability, and frontier semantics.