# Lemon Goals
Generated: 2026-11-02T05:42:47.617Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: improve.goal-contracts
title: Lemon Goals
summary: Define measurable candidate targets and constraints while preserving exact units, starting measurements, and original instructions.
kind: reference
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/goals
---
# Lemon Goals
## Definition
A Lemon Goal states the measured result a saved Harness should reach and the directions permitted to get there. Its accepted target identities, conditions, units and original instructions explain later candidate work.
## Fields, states, or lifecycle rules
- A criterion refers to an exact benchmark metric, Policy, Rubric or Case scope.
- Conditions can express absolute thresholds, increases, decreases or preservation where supported by that metric.
- Resource criteria keep their actual units, such as latency, tokens or cost.
- Starting measurements are recorded when available; an absent measurement is shown as unmeasured.
- The Goal and its Session are created together.
- Original accepted instructions and earlier results remain attributable.
## Define numerical criteria
Choose the criterion and a supported condition. Read the unit before entering the target: a score percentage, a count and a latency value have different meanings.
An absolute target states a threshold. A relative target states a change from the relevant starting measurement. Preserve the exact relationship rather than substituting a rounded display value. Percentage reduction from a measured zero cannot be interpreted as a positive reduction.
Choose constraints and an improvement direction that match the authorized scope. The available direction options can restrict work to prompts, model choice, a model family or configuration. They do not select a fixed implementation strategy for the agent.
## Starting point
Select the saved Harness Version whose behavior should change. Inspect existing comparable measurements when present. An initial evaluation is not a universal creation prerequisite; the current target and admission rules determine what remains to be measured.
Missing data does not become a zero score, inferred baseline or invented success claim. The Session keeps starting evaluation and candidate evaluation distinct.
## Traceability
Users edit or submit the current Goal through its supported controls. Accepted settings and instructions are captured automatically for interpretation and replay. Users do not need to name, publish or manage a separate prompt/configuration version.
Read Goal, Results and Evolution together when deciding whether a candidate satisfied the requested outcome. A completed Session and an achieved Goal are different statements.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Start a Lemon Goal Session](/docs/improve/start-improvement-session)
- [Candidates and Results](/docs/improve/candidates-and-frontier)
- [Run Details and Metadata](/docs/benchmark-evaluations/run-details)
{% /related-card-grid %}
---
id: improve.start-session
title: Start a Lemon Goal Session
summary: Choose a saved Harness, numerical criteria, permitted changes, and execution settings, then start goal-driven work.
kind: task
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/start-improvement-session
---
# Start a Lemon Goal Session
Start a Session when you want Teammately to improve a saved Harness toward an explicit measured outcome.
## Prerequisites
- A selected Benchmark Version and saved starting Harness.
- Permission to start work in that scope.
- Measurable criteria and a clear boundary for permitted changes.
- An available execution machine and model choice from the supplied catalog.
## Before and after
| Before | After |
| --- | --- |
| A saved candidate and intended change | An accepted Goal with exact criteria |
| Available starting measurements | Recorded starting context, with missing values kept unmeasured |
| Free-form instructions | Original instructions attached to the new Session |
| Candidate work has not started | The Goal and Session are created together |
## Steps
1. Open **Harness improvement → Lemon Goal**.
2. Choose the saved Harness Version to improve.
3. Add numerical criteria and check their supported conditions, units and target values.
4. Select the permitted improvement direction and write any additional instructions.
5. Review available starting measurements. Missing initial results do not require inventing a baseline.
6. Choose the machine, execution count, candidate settings and available model option.
7. Review the selected scope and start the Session.
8. Follow the conversation. Answer an explicit question when one appears, and inspect Goal, Results, Evolution and Harnesses as work progresses.
The agent chooses useful actions within the accepted scope. Selecting a direction does not prescribe a fixed sequence of semantic steps.
## Object and state changes
Starting records the Goal and Session atomically. Subsequent work can produce candidate Harness Versions, evaluations, findings and usage records. Accepted inputs remain attached to that work rather than being rewritten by later project settings.
## Success criteria
- Criteria refer to the intended objects and preserve their actual units.
- The saved starting Version and original instructions are identifiable.
- Candidate conclusions refer to actual recorded measurements.
- Completion is interpreted from the reported outcome, not status alone.
## Common failure modes
- Selecting a different saved Version than intended.
- Mistaking unmeasured values for zero.
- Using a rounded display as the exact target formula.
- Treating Session completion as proof that every criterion was achieved.
- Using candidate work to hide a mistaken Case or Rubric.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Lemon Goals](/docs/improve/goals)
- [Candidates and Results](/docs/improve/candidates-and-frontier)
- [Session Conversation and History](/docs/improve/chronology-and-trajectories)
- [Evaluation Results](/docs/benchmark-evaluations/results)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Benchmark run troubleshooting](/docs/troubleshooting/benchmark-runs)
- [Benchmark Results Changed Unexpectedly](/docs/troubleshooting/benchmark-results-changed-unexpectedly)
{% /related-card-grid %}
---
id: improve.candidates-frontier
title: Candidates and Results
summary: Interpret exact candidate Harness Versions, comparable evaluations, constraints, and retained results in a Lemon Goal Session.
kind: reference
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/candidates-and-frontier
---
# Candidates and Results
## Definition
A candidate is an identifiable Harness change examined during a Lemon Goal Session. Its source, ancestry, accepted Goal and actual evaluations explain what was attempted and what the result supports.
## Fields, states, or lifecycle rules
- An evaluated candidate identifies an exact saved Harness Version.
- Results retain the Benchmark Version and measurement population.
- Starting evaluation and candidate evaluation have different roles.
- A missing, failed or incomparable evaluation does not establish improvement.
- Retained candidates remain distinguishable from every explored draft or branch.
## Read Results
Open the Session's **Results** panel to inspect candidate outcomes and comparison context. Its Evaluations view links the recorded executions. Check completeness and criteria before interpreting a lead.
A candidate can improve one target while violating another constraint. Keep that tradeoff visible. A high overall score cannot replace a missing judgment on a protected criterion.
The retained result is not automatically the newest candidate. An unsuccessful direction can still explain why the agent tried another change, while an incomparable result cannot justify a numerical improvement claim.
## Read Evolution
Evolution connects progress and execution history. Strategies describe the approaches used in the Session. The chart remains available after work ends; Session completion does not erase the sequence that produced the result.
Use **Harnesses** to inspect the actual candidate artifacts rather than inferring code changes from narration. Saving or evaluating a candidate is distinct from deciding to use it in a future benchmark execution.
## Population and history
Compare against the same Benchmark Version and recorded conditions. Ordinary candidate scores use the reference Run selected before outcomes were known. Extra independent Runs retain their own history instead of silently contributing only their best Trials.
A focused observation can guide exploration without replacing the complete comparison required by the Goal. Read the reported conclusion and its measurements before deciding how to use the resulting candidate.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Lemon Goals](/docs/improve/goals)
- [Session Conversation and History](/docs/improve/chronology-and-trajectories)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Harnesses](/docs/assets/harnesses)
{% /related-card-grid %}
---
id: project-settings.run-metadata
title: Run Details and Metadata
summary: Inspect the identity, recorded settings, source, telemetry, and status that explain an evaluation Run.
kind: reference
product_area: benchmark_evaluations
status: stable
updated: 2026-10-30
canonical: /docs/benchmark-evaluations/run-details
---
# Run Details and Metadata
## Definition
A Run's details explain which candidate was measured, against which Benchmark Version, under which execution conditions. Read the recorded Run rather than today's project defaults.
## Fields, states, or lifecycle rules
- Managed Runs identify a saved Harness Version and captured runtime.
- Imported Runs identify the external submission and its exact Cases.
- Planned Trials, machine allocation and evaluation settings describe the recorded execution.
- Status distinguishes output progress from rubric evaluation progress.
- Labels and descriptive metadata help interpretation but do not replace issued identities.
- Tokens, latency and cost are nullable measurements. Missing capture remains unknown.
## Run history and score use
Use Run history to inspect independent executions of the same candidate. **Used for score** identifies the reference selected before outcomes were known. **Run evaluation** reopens matching work; **Run again** deliberately adds an independent Run.
A later label or metadata change does not make two different execution populations identical. Retain the exact Run and Trial links when recording a comparison or asking an expert about a response.
## Settings versus observations
Machine allocation and planned Trial count are accepted execution commitments. Measured latency, token use and actual responses are observations produced afterward. Keep both when explaining an operational difference.
Historical descriptive fields remain attached to their Runs. They do not imply that there is a current project-level Run Metadata configuration tab or that editing today's settings changes accepted history.
## Using details in follow-up work
Link an expert to the relevant response and criterion rather than only an aggregate. When copying an External Agents task, confirm whether its optional reference Run represents the code the agent will change. When starting Lemon Goal, inspect the selected starting candidate and available measurements.
Never put credentials in labels, metadata or Case content. Grant secrets through the owning settings and Harness controls.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Run a Benchmark Evaluation](/docs/benchmark-evaluations/run-evaluation)
- [Inspect Evaluation Results](/docs/benchmark-evaluations/inspect-results)
- [Work with External Agents](/docs/improve/external-agents)
{% /related-card-grid %}