# Working with Lemon
Generated: 2026-11-02T05:42:43.208Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: concepts.lemon
title: Working with Lemon
summary: Find Lemon assistance, expert elicitation, case synthesis, interactive Harness development, and benchmark-driven Harness improvement within Teammately.
kind: concept
product_area: introduction
status: stable
updated: 2026-09-15
canonical: /docs/concepts/lemon
---
# Working with Lemon
Lemon is Teammately’s shared AI agent identity. The platform keeps your project context, expert contributions, governed standards, coverage, and reusable assets. Lemon works within those contexts and returns suggestions, proposed changes, or generated material for your team to inspect.
## Definition
General Lemon assistance helps develop coverage dimensions, Topics, Scenarios, and project wording. Lemon Elicit prepares expert work, supports interviews and adaptive reviews, learns from contributions, and proposes standards. Lemon Weave synthesizes Cases, supporting materials, and training material. Worlds and Personas remain **Early reviewers only** Assets placeholders; this identity does not expand their authoring or execution contracts. Lemon Code supports interactive Harness development through a conversation connected to the current Harness draft. Lemon Goal explores and evaluates Harness improvements against a benchmark within an Improvement Session.
The same Lemon identity appears across these activities. Task titles and project or benchmark context tell you which work you are viewing. The Work panel collects supported activities and provides a separate view of human expert contributions.
## Decision checkpoint
| Your task | Where to work | What to inspect |
| --- | --- | --- |
| Develop coverage structure | Coverage Facets and coverage planning | Lemon’s proposed dimensions, Topics, or Scenarios |
| Understand expert judgment | Expert Contributions | Lemon Elicit’s preparation, expert responses, and proposed interpretations |
| Fill a gap with newly constructed cases | Coverage Design → Canvas | Lemon Weave’s Cases and supporting material |
| Reuse an existing case | Case Foundry or Assets → Cases | Existing case identity and suitability for the benchmark |
| Improve a Harness against a benchmark | Harness improvement → Lemon Goal | Lemon Goal’s candidates, evaluation results, and Session state |
| Develop a harness | Assets → Harnesses | Lemon Code’s attached context, file changes, and draft version |
Case Foundry supports reuse as well as synthesis. Opening it does not mean every case was generated by Lemon Weave. Reference Materials inform the work; approved policies and rubrics retain their separate authority.
## Review the result in its owning workflow
Inspect a proposed dimension before adopting it. Review a harness change before applying it to the draft. Check generated cases against the intended coverage. Expert contributions retain the person’s identity, and Lemon’s interpretation remains distinguishable from accepted standards.
Lemon’s identity does not replace a model being evaluated, a speaker in an imported trajectory, a rubric evaluator, or an imported-log classifier. Evaluation results remain attributable to their criteria and configuration. Generated training material is separate from training execution and deployment.
{% example-demo title="From a coverage question to a harness edit" %}
Ask Lemon to propose dimensions for conflicting-document questions. Review the proposal, then use Case Foundry to find suitable existing cases or generate missing cases with Lemon Weave. An expert contribution lets Lemon Elicit clarify the controlling distinction. In the harness editor, ask Lemon Code to propose a change and inspect its file diff before applying it to the draft.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Expert elicitation with Lemon](/docs/concepts/correctness-elicitation)
- [Lemon Weave](/docs/concepts/weave)
- [Lemon Goal](/docs/concepts/coevolve)
- [Assets](/docs/assets)
- [Agent Setup](/docs/agent-setup)
{% /related-card-grid %}
---
id: concepts.correctness-elicitation
title: Expert elicitation with Lemon
summary: Turn tacit specialist judgment into attributable contributions, governed policies, applicability conditions, and binary rubrics.
kind: concept
product_area: correctness_elicitation
status: stable
updated: 2026-10-30
canonical: /docs/concepts/correctness-elicitation
---
# Expert elicitation with Lemon
Correctness Elicitation is the capability for turning specialist judgment into explicit, reusable correctness specifications. It handles the parts of AI behavior that cannot be settled by a generic score: domain preferences, exceptions, conflicts between sources, applicability boundaries, unacceptable failure modes, and the supporting information an expert needs before making a decision.
## Definition
Elicitation begins before the expert opens a task. Lemon Elicit can organize relevant Reference Materials, cases, candidate responses, possible policies, rubric questions, and unresolved conflicts into a focused Contribution. The expert then works through forms, chat, interviews, case review, or checkpoints according to the requested components.
The contribution remains attributable. Accepted learning can be materialized into policies, rubrics, cases, or coverage observations, while drafts and unresolved statements keep their own state. Correctness Governance owns the resulting policies and rubrics; Expert Contributions owns the benchmark-scoped human work that produced them.
## Decision checkpoint
| Need | Elicitation method | Durable destination |
| --- | --- | --- |
| Confirm a known rule across several cases | Focused form or case review | Policy, applicability, or rubric contribution |
| Discover reasoning that is hard to pre-structure | Chat or interview | Attributable transcript, checkpoints, and contributed artifacts |
| Resolve disagreement or ambiguity | Targeted comparison and checkpoint | Explicit unresolved or accepted statement |
| Identify missing benchmark behavior | Cases plus coverage questions | Contributed case or coverage observation |
| Tune guidance, alternatives and presentation | Project Settings and Assets | Lemon instructions, Comparison Directions and Review Screens |
## Why preparation matters
An expert should not have to reconstruct the project, search for the controlling source, or infer why a case was selected. Project Context gives the agent the stable brief. Reference Materials provide indexed project knowledge. The Contribution selects the benchmark results and states the objective. A selected Review Screen controls presentation. Assets owns Comparison Directions; Project Settings owns Lemon instructions for configured activities.
This separation preserves authority. Reference material can inform an answer without becoming a policy. Agent-authored draft wording can focus the expert without becoming approved. A completed expert task can contribute supporting information without automatically changing every project artifact.
## Relationship to the product
Correctness Elicitation is broader than any single screen. Use **Expert Contributions** to request and track benchmark-scoped expert work. Use **Correctness Governance** to inspect and maintain policies and rubrics after they are materialized. Use **Agent Setup** to configure what review agents understand, how they behave, and what experts see.
The capability also returns learning to Coverage Engineering and Weave. An expert may identify a missing behavior combination, contribute a new case, or explain that existing material is insufficient. Those outputs should update the owning coverage or case artifacts instead of being flattened into a general review note.
{% example-demo title="Exception handling" %}
An agent prepares three cases where a procurement rule might allow an exception, attaches the controlling policy material, and asks a specialist to distinguish approved exceptions from escalation-only situations. The specialist completes a case review and confirms a checkpoint. The accepted contribution materializes a scoped policy and binary rubric, while one unresolved source conflict becomes a coverage observation for follow-up.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Correctness Governance](/docs/correctness-governance)
- [Agent Setup](/docs/agent-setup)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Human Approval Boundaries](/docs/governance/human-approval-boundaries)
- [Policies](/docs/object-model/policies)
- [Rubrics](/docs/object-model/rubrics)
{% /related-card-grid %}
---
id: concepts.weave
title: Lemon Weave
summary: Construct deliberate challenge sets from coverage structure, canonical cases, variants, multimodal materials, and supported worlds.
kind: concept
product_area: weave
status: stable
updated: 2026-10-30
canonical: /docs/concepts/weave
---
# Lemon Weave
Lemon Weave is the case-construction capability inside Teammately correctness infrastructure. It turns structured coverage intent into the cases, response variants, supporting materials, and supported environments needed to challenge a specialist AI system. Its goal is deliberate representation, not undirected synthetic volume.
## Definition
Coverage Engineering supplies the structure: Dimensions, Topics, Scenarios, coverage tuples, and known gaps. Lemon Weave uses that structure to prepare candidate cases that exercise meaningful combinations and boundaries. Cases follow the project's Input Schema, so their primary input and required materials have a consistent, inspectable shape.
A case can include text, chat messages, structured data, images, documents, tabular files, presentations, source text, or audio when the Project Input Schema accepts those artifacts. Static support belongs to case materials. An executable or queryable environment is a separate world boundary and should only be used where the product supplies an inspectable world reference and runtime.
## Decision checkpoint
| Construction need | Use | Verify before benchmark membership |
| --- | --- | --- |
| Add a known real example | Assets → Cases or dataset import | Input and materials conform to Project Input Schema |
| Cover a missing facet combination | Coverage Design and Case Foundry | The case targets a named tuple or gap |
| Generate a meaningful output variation | Case construction plus Comparison Directions | The idea guides variation without pretending the output is already reviewed |
| Include supporting files | Canonical case materials | Artifact family and extension are accepted by the project |
| Exercise changing state or tools | Supported World | World identity, capabilities, visibility, and lifecycle are explicit |
## Deliberate construction
Case count is a weak target. A useful challenge set explains why every important slice exists and which behavior boundary it exercises. Scenarios provide reusable ways to instantiate a behavior problem. Coverage Design shows where cases already exist and where the benchmark remains thin. Case Review lets operators inspect generated materials before those cases become trusted dataset members.
Comparison Directions belong to Assets. They guide how a review agent should vary candidate responses—for example, changing source grounding or reasoning approach—without serving as a coverage taxonomy or an automatically accepted collection of variants.
## Canonical case boundary
`content.input` is the primary case input. Optional `content.case_materials` contains declared supporting values or artifacts. `record_content.case_view` is a rendered projection for users and execution adapters; it is not a second source of truth. Static runtime delivery uses case-material references. Executable worlds use a world instance reference.
This distinction keeps the same case understandable to case authors, experts, harness code, and evaluation services. It also lets the system reject material that is missing, undeclared, or incompatible before a Run produces misleading results.
{% example-demo title="Conflicting-source case" %}
Coverage Design identifies a thin tuple combining policy exception, superseded source, and high customer impact. A Scenario describes how to pair a current rule with a plausible older document. Weave creates a chat input and attaches both documents as case materials. Case Review confirms that the conflict is visible and realistic before the case enters the benchmark dataset snapshot.
{% /example-demo %}
## Related workflows
{% related-card-grid title="Related workflows" %}
- [Project Input Schema](/docs/project-settings/input-schema)
- [Coverage Design](/docs/coverage-design)
- [Benchmark Datasets](/docs/benchmark-datasets)
{% /related-card-grid %}
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Assets](/docs/assets)
- [Cases](/docs/object-model/cases)
- [Comparison Directions](/docs/assets/comparison-directions)
{% /related-card-grid %}
---
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-10-30
canonical: /docs/concepts/coevolve
---
# Lemon Goal
Lemon Goal is the capability for improving candidate behavior while keeping the benchmark, standards and measurements connected. A useful change has an identifiable implementation, an explicit goal and actual results.
## Definition
The current product realizes candidate work through **Harness improvement → Lemon Goal** and **External Agents**. Lemon Goal coordinates work on a saved Harness. External Agents supplies a scoped task for a coding agent in the customer's real repository.
Both paths preserve the selected Benchmark Version and the criteria used to assess behavior. They differ in execution ownership: the copied External Agents task is not a hosted Teammately Session, and it does not require source upload or a Teammately Harness.
## 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.
The five-capability loop keeps these responsibilities connected without turning every finding into an automatic approval or dataset change.
## 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: assets.overview
title: Assets
summary: Reuse project Cases, Worlds, Personas, Harnesses, Comparison Directions, and Review Screens across benchmark work.
kind: concept
product_area: assets
status: stable
updated: 2026-10-30
canonical: /docs/assets
---
# Assets
Assets holds reusable project objects selected by benchmark and expert workflows. Current categories are **Cases**, **Worlds**, **Personas**, **Harnesses**, **Comparison Directions** and **Review Screens**.
## Definition
Cases describe the situations to judge. Harnesses contain executable candidate logic and declared dependencies. Comparison Directions guide useful response alternatives, and Review Screens control expert presentation.
Worlds describes immutable source snapshots and their separate execution context. Worlds and Personas display **Early reviewers only**. Personas is intended for reusable simulated participants in Trialground; its representation and execution contract are defined separately when implemented.
**Weights training** belongs to the Benchmark workspace. It connects selected criteria to training datasets, packages, provider jobs and evaluation, rather than adding another empty Assets tab.
## Decision checkpoint
| Need | Open | Boundary |
| --- | --- | --- |
| Inspect or prepare a reusable situation | Cases | Canonical input and declared materials |
| Edit candidate execution logic | Harnesses | Draft, saved Version and explicit use |
| Guide meaningful alternatives | Comparison Directions | Guidance, not a correctness judgment |
| Design expert presentation | Review Screens | Selectable presentation asset |
| Understand environment context | Worlds | Immutable source and isolated execution copy |
| Prepare a trainable model candidate | Benchmark → Weights training | Dataset, package, job and evaluation |
## Reuse and selection
A project asset can support more than one Benchmark. That reuse does not automatically add every Case to every dataset or activate every Harness Version.
Benchmark Datasets owns current Case membership and Snapshots. A saved Harness Version remains the exact candidate used by a recorded Run, even when its Draft changes later.
Use Cases and Project Input Schema for static supporting material. A document does not require a World simply because an agent reads it. Harnesses retain their tool implementations and declared dependencies; the retired standalone Project Tools category does not become a new authority over those capabilities.
## Preserve attribution
Inspect the selected asset identity when preparing a Contribution, evaluation or improvement task. A human-readable title helps navigation but cannot replace the exact saved content and scope used by accepted work.
A screen, direction or generated Case is not automatically an approved standard. Policies and Rubrics retain their own governance lifecycle.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Cases](/docs/assets/cases)
- [Harnesses](/docs/assets/harnesses)
- [Worlds](/docs/assets/worlds)
- [Personas](/docs/assets/personas)
- [Comparison Directions](/docs/assets/comparison-directions)
- [Review Screens](/docs/assets/review-screens)
- [Weights Training](/docs/weights-training)
{% /related-card-grid %}
---
id: agent-setup.overview
title: Agent Setup
summary: Maintain the Project Agent Brief and Reference Materials used by Teammately agents across benchmark work.
kind: concept
product_area: agent_setup
status: stable
updated: 2026-10-30
canonical: /docs/agent-setup
---
# Agent Setup
Give agents the project understanding they need before they prepare coverage, expert work or candidate improvements. Keep the project's stable purpose separate from its source materials and governed standards.
## Definition
Project understanding has two parts: **Project Context**, which edits the Project Agent Brief, and **Reference Materials**, which connects source material and exposes Indexed Reference. These are reusable project foundations and are also available through Project Settings.
The brief explains purpose, users, important terminology and constraints. Reference Materials supplies the documents and source content agents retrieve. A source refresh does not silently rewrite the brief.
## Decision checkpoint
| Need | Open | Scope |
| --- | --- | --- |
| Explain stable project purpose | Project Context | Project Agent Brief |
| Connect and inspect source material | Reference Materials | Project sources and indexed blocks |
| Edit guidance for configured Lemon activities | Project Settings → Lemon instructions | Project override or inherited guidance |
| Guide response alternatives | Assets → Comparison Directions | Reusable comparison guidance |
| Design expert presentation | Assets → Review Screens | A selectable review asset |
| Ask one specialist question | Expert Contributions | One Benchmark request |
## Keep context and authority distinct
A source document can inform an agent without becoming an approved Policy. The brief or Lemon instructions cannot supply expert approval. Comparison Directions can vary responses without deciding which response is correct.
Put a one-time objective in its Contribution or Lemon Goal. Put a stable project-wide expectation in the brief or the appropriate Lemon instruction. This keeps an earlier accepted request interpretable after settings change.
## Maintain project understanding
Review the brief when product purpose, terminology or domain boundaries change. Verify that controlling material is actually present in Indexed Reference after source processing. A connected account alone does not establish that its intended documents are retrievable.
Keep disagreements between sources visible. Use a scoped Expert Contribution when a qualified person must decide which rule controls, then maintain the accepted standard in Correctness Governance.
The Project Memo in General settings remains descriptive text for people. It is not injected as agent context.
## Related reference pages
{% related-card-grid title="Related reference pages" %}
- [Project Context](/docs/agent-setup/project-context)
- [Reference Materials](/docs/agent-setup/reference-materials)
- [Lemon Instructions](/docs/project-settings/lemon-instructions)
- [Comparison Directions](/docs/assets/comparison-directions)
- [Review Screens](/docs/assets/review-screens)
{% /related-card-grid %}