# Lemon Goal
Generated: 2026-11-06T00:55:25.963Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: concepts.coevolve
title: Lemon Goal
summary: Use benchmark results to explore candidate improvements and return unresolved correctness or coverage questions to their owning workflows.
kind: concept
product_area: coevolve
status: stable
updated: 2026-11-06
canonical: /docs/concepts/lemon-goal
---
# Lemon Goal
Lemon Goal improves a saved Harness toward a benchmark objective through candidate experiments in Teammately. A useful change has an identifiable implementation, an explicit Goal and actual results.
## Definition
Open **Harness improvement → Lemon Goal** to define the measured outcome, starting Harness and permitted changes. Lemon Goal investigates failures, develops candidates and tests them through Trialground.
**Harness improvement** also contains **External Agents**, a separate workflow that supplies a scoped task and pinned benchmark context for your coding agent in your own repository. Both workflows preserve the selected Benchmark Version and criteria.
## Decision checkpoint
| Situation | Choose | Inspect |
| --- | --- | --- |
| A saved Harness should meet numerical targets | Lemon Goal | Accepted criteria, candidate Versions and evaluations |
| Application code should change in your repository | External Agents | Pinned task context and actual before/after behavior |
| A result exposes an unclear rule | Expert Contribution | Specialist judgment and artifact decisions |
| Important input situations are missing | Coverage Design | Requirements and explicit Case adoption |
## Learn from actual results
Inspect the full planned population before deciding a candidate is stronger. A focused success can guide another direction without replacing the complete comparison required by the Goal.
A candidate can gain on one criterion and regress another. Retained results and the Session's Evolution history should make that tradeoff explainable. A new Version is not automatically the best candidate.
## Preserve the goal and the work
Lemon Goal records original instructions, targets and the starting candidate. Its conversation and Goal, Results, Evolution and Harnesses panels connect requested work to returned artifacts and measurements. A completed Session means the agent concluded; the reported outcome explains whether the Goal was achieved.
External Agents relies on the coding agent to inspect actual customer code, implement within the permitted scope and submit supported results. Setup or retrieval alone does not complete that task.
## Return new questions upstream
Candidate work may expose a mistaken Case, unresolved applicability or an unrepresented input condition. Route those questions to the owning governance, expert or coverage workflow. Do not hide a broken standard by changing the candidate until it passes an ambiguous test.
Return the finding to the relevant expert, governance, or coverage workflow so your team can decide how it should affect the benchmark.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Harness Improvement](/docs/improve)
- [Start a Lemon Goal Session](/docs/improve/start-improvement-session)
- [Work with External Agents](/docs/improve/external-agents)
- [Coverage Design](/docs/coverage-design)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
---
id: improve.overview
title: Harness Improvement
summary: Improve candidate behavior with Lemon Goal or give your coding agent a scoped External Agents task.
kind: concept
product_area: improve
status: stable
updated: 2026-11-06
canonical: /docs/improve
---
# Harness Improvement
Harness improvement offers two ways to act on benchmark results: **Lemon Goal** coordinates goal-driven work inside Teammately, and **External Agents** prepares a task for your coding agent in your own repository.
## Definition
Lemon Goal starts from a selected saved Harness and measurable criteria. It creates the Goal and its Session together, preserves the original instructions and follows candidate changes through actual evaluations.
External Agents pins a Benchmark Version and optionally selected criteria or a reference Run. It supplies the correctness context while your agent changes the real application. A Teammately Harness or source upload is optional for that path.
## Decision checkpoint
| Need | Choose | Boundary |
| --- | --- | --- |
| Evolve a saved Harness toward numerical targets | Lemon Goal | Recorded Goal, Session, candidates and evaluations |
| Change application code in your own environment | External Agents | Copied task and exact benchmark context |
| Clarify a mistaken standard | Expert Contribution or Correctness Governance | Human judgment and artifact approval |
| Add missing input situations | Coverage Design | Requirements and explicit Case adoption |
## Work with Lemon Goal
Choose the starting Harness, criteria, permitted direction and execution settings. Read actual starting measurements where available; missing measurements stay unmeasured. Starting creates the Goal and begins its Session, capturing your targets and original instructions together.
Use the conversation to read the agent's conclusions, answer explicit questions and provide authorized steering. Goal, Results, Evolution and Harnesses expose the current purpose, measurements, candidate history and source artifacts.
Completed means the agent concluded its work. Read the reported outcome to determine whether the Goal was achieved. Stopping a Session preserves its recorded work.
## Work with an external agent
Copy the task from External Agents. Your coding agent retrieves the pinned context, inspects your repository and carries out the requested implementation and evaluation. The agent works in your repository while Teammately supplies the selected benchmark context and assessment results.
Imported responses and managed Harness executions return to ordinary Benchmark Evaluations. Your engineer reviews the comparison and decides which implementation changes to adopt.
## Keep the responsible object clear
A candidate failure can expose an incorrect Case, an applicability problem or a missing coverage slice. Fixing candidate code is not the answer to every benchmark discrepancy. Preserve the exact candidate and Benchmark Version so the next action can be assessed from the same recorded population.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Start a Lemon Goal Session](/docs/improve/start-improvement-session)
- [Lemon Goals](/docs/improve/goals)
- [Work with External Agents](/docs/improve/external-agents)
- [Candidates and Results](/docs/improve/candidates-and-frontier)
- [Session Conversation and History](/docs/improve/chronology-and-trajectories)
- [Lemon Goal](/docs/concepts/lemon-goal)
{% /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.work-evolve
title: Work with External Agents
summary: Copy a benchmark-scoped task for your coding agent to implement and evaluate in your real application repository.
kind: task
product_area: improve
status: stable
updated: 2026-10-30
canonical: /docs/improve/external-agents
---
# Work with External Agents
External Agents gives your coding agent a concrete improvement task grounded in the selected Benchmark Version. The agent works in your real repository; Teammately supplies the applicable Cases, Policies, Rubrics and recorded results.
## Prerequisites
- A selectable Benchmark Version.
- Access to the application repository and authorization for the intended changes.
- A coding agent connected through the setup supplied with the task.
- An optional reference Run that genuinely represents the application starting point.
## Steps
1. Open **Harness improvement → External Agents**.
2. Select the Benchmark Version. Changing it clears local criterion and reference-Run selections.
3. Focus on the whole Benchmark or choose up to 20 approved and applicable Policy and Rubric Versions.
4. Optionally select one individual reference Run. No Run is silently selected.
5. Choose the allowed improvement direction: supported practices, prompt only, model only, the same model family, or model configuration only.
6. Copy the task, including setup instructions when needed, into your coding-agent conversation.
7. Have the agent inspect the actual repository, retrieve the pinned criteria and Run context, implement the change and evaluate it.
8. Inspect resulting Runs through ordinary Benchmark Evaluations.
The copied task includes the Project Agent Brief when present. Credentials do not belong in that text.
## Execution choices
A Teammately Harness and source upload are optional. Customer-executed responses are the default path for the agent's real application. Managed Harness execution requires a deliberate choice.
The product data MCP supplies read-only context, instructions, results and comparisons. The CLI owns local files and submission operations. The documentation MCP only retrieves these manuals.
Start with [CLI authentication](/docs/cli/authentication) and [product MCP setup](/docs/cli/mcp), then follow [external output submission](/docs/cli/external-outputs) or the optional [managed Harness workflow](/docs/cli/managed-harness).
## Object and state changes
The composer keeps selections locally and copies text. It creates no hosted agent Session, transcript, durable handoff object, automatic code adoption or Harness activation. Later submitted responses or managed execution create their own ordinary Run records.
## Success criteria
- The task preserves the intended Benchmark Version and criteria.
- A selected reference Run is checked against actual code.
- Implementation and comparison use actual pre-change and post-change behavior.
- Accepted responses and candidate identity remain attributable.
## Common failure modes
- Stopping after tool setup or context retrieval.
- Assuming a Harness upload is mandatory.
- Treating copied text as an executed Session.
- Using a reference Run from unrelated code.
- Claiming private agent work before returned artifacts or results exist.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Harness Improvement](/docs/improve)
- [Import External Evaluation Outputs](/docs/benchmark-evaluations/output-mapping)
- [Evaluation Results](/docs/benchmark-evaluations/results)
- [Project Context](/docs/agent-setup/project-context)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Output mapping troubleshooting](/docs/troubleshooting/output-mapping)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}
---
id: coverage-management.overview
title: Coverage Design
summary: Use Canvas to define required input coverage and Inbox to decide how new findings affect benchmark membership.
kind: concept
product_area: coverage_management
status: stable
updated: 2026-10-30
canonical: /docs/coverage-design
---
# Coverage Design
Coverage Design applies reusable project facets to one Benchmark. Use **Canvas** to plan and inspect input coverage, and **Inbox** to decide whether new findings should change the selected Cases.
## Definition
A coverage requirement names an input situation and how it should be represented. It can require a minimum Case count or record an observation. Dimension ontology values, Topics and Scenarios identify the intended slice; distribution settings describe its share of the active benchmark population.
Canvas connects those requirements to actual selected Cases. A large total does not establish that an important combination is present, and unknown classification does not establish absence.
## Decision checkpoint
| Need | Use | Result |
| --- | --- | --- |
| Define the intended behavior space | Canvas requirements and settings | Explicit coverage obligations |
| Inspect a slice or combination | Canvas selection and matrix | Matching Cases, unknowns and remaining need |
| Prepare more Cases | Case preparation | Reviewable candidates and materials |
| Act on an expert or Fieldloop finding | Inbox | An explicit adoption decision |
| Freeze the selected population | Benchmark Datasets → Snapshots | An immutable Benchmark Version |
## Work from Canvas
Describe the Benchmark intent, select the relevant facets and inspect count or distribution requirements. Examine Cases behind a count before deciding that a gap is resolved. Distinguish requirements from observations and current membership from available project Cases.
Stories and their tuples describe meaningful situations used in planning and Case preparation. Case Foundry coordinates preparation; Case Review is where prepared inputs and materials are inspected. These mechanisms support Canvas work rather than replacing its current requirement and membership view.
## Materials and input shape
Project Input Schema owns allowed artifact families, accepted formats and required material keys. Coverage Design does not add another Materials configuration. A tuple can require an allowed artifact but cannot remove a required input or enable an unsupported format.
## Act from Inbox
Inbox links attributable input-coverage findings to possible dataset changes. Review each observation or proposed Case separately. Generating a Case stages another item; it does not automatically add membership. A resolved report can contain declined or withdrawn items.
Existing Snapshots and Runs retain their recorded population. Create a new Snapshot when changed membership or standards should define a later evaluation.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Coverage Design Settings](/docs/coverage-design/settings)
- [Input Coverage Inbox](/docs/coverage-design/inbox)
- [Coverage Stories](/docs/coverage-design/coverage-stories)
- [Review Prepared Cases](/docs/coverage-design/case-review)
- [Benchmark Datasets](/docs/benchmark-datasets)
- [Project Input Schema](/docs/project-settings/input-schema)
{% /related-card-grid %}
---
id: expert-contributions.request
title: Request an Expert Contribution
summary: Write a focused request, choose an expert, attach relevant project context, and inspect the prepared plan before requesting review.
kind: task
product_area: expert_contributions
status: stable
updated: 2026-11-06
canonical: /docs/expert-contributions/request-contribution
---
# Request an Expert Contribution
Use the Contribution composer to explain what specialist judgment the Benchmark needs. The request blueprint supplies context; the prepared plan makes the resulting work inspectable.
## Prerequisites
- A selected Project and Benchmark.
- An eligible expert.
- A concrete objective or unresolved question.
- Relevant Cases or source context when the question depends on them.
## Steps
1. Open **Expert Contributions → Contributions** and create a request.
2. Write the objective or mission in the request blueprint.
3. Type **@** to attach relevant context or **/** to choose available skills. Use attachments to identify the intended objects rather than relying on similar titles.
4. Choose the expert and inspect the displayed recommendations or activity where useful.
5. Attach the Cases, standards and review assets needed to explain the judgment.
6. Submit the request for planning.
7. Inspect the prepared direction, scope and activities before **Request expert review**.
8. Follow attributable responses, decisions and completion through the Contribution.
## Context and review assets
The composer can include Policies, Rubrics, Dimensions and ontology values, Topics and Topic Groups, Scenarios, Benchmark Cases, Comparison Directions, a Review Screen and Fieldloop Threads.
Choose one Review Screen. Comparison Directions guide alternatives; review-component selections express the kinds of work the planner can prepare. They do not approve the resulting content or force one conversational sequence.
Include Cases when they make the question concrete. A direct expert inquiry can begin with the relevant project context, reference material, and a clear learning objective.
## Object and state changes
Creation records the request, selected expert and contextual scope. Planning prepares the direction and activities; alignment authorizes the intended work. Assignment, visible task progress, artifact decisions and final Contribution completion remain separate.
Already accepted or completed work is not silently replaced by a later planning or settings edit.
## Success criteria
- The expert's requested judgment is clear.
- Attached objects and source context match that judgment.
- The prepared plan stays within the request.
- Review presentation and response alternatives have the intended scope.
## Common failure modes
- Writing a broad mission that leaves the learning objective unclear.
- Treating a comparison asset as an approved standard.
- Attaching more than one Review Screen.
- Using a persistent instruction for a one-time question.
- Assuming task completion approves every contributed artifact.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
- [Contributed Artifacts](/docs/expert-contributions/contributed-artifacts)
- [Review Screens](/docs/assets/review-screens)
- [Comparison Directions](/docs/assets/comparison-directions)
{% /related-card-grid %}
## Related troubleshooting pages
{% related-card-grid title="Related troubleshooting pages" %}
- [Expert Contribution problems](/docs/troubleshooting/expert-contributions)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
{% /related-card-grid %}