# Lemon Instructions Generated: 2026-11-02T05:43:22.111Z Source build: local Canonical docs: https://teammately.ai/docs --- id: agent-setup.behavior-instruction title: Lemon Instructions summary: Edit current Markdown guidance for configured Lemon activities with project inheritance and automatic change history. kind: reference product_area: project_settings status: stable updated: 2026-10-30 canonical: /docs/project-settings/lemon-instructions --- # Lemon Instructions ## Definition Lemon instructions let authorized administrators and project managers maintain guidance for the configured activities that prepare, conduct and evaluate correctness work. Open **Admin → Organization Settings → Lemon instructions** for workspace guidance or **Project Settings → Lemon instructions** for a project override. A saved project instruction takes precedence over workspace guidance, then the reviewed default. ## Fields, states, or lifecycle rules Each configured activity has one Markdown document: - Review expert feedback. - Draft policies. - Draft case-specific checks. - Plan expert interviews. - Summarize expert interviews. - Plan expert contributions. - Adjust contribution follow-ups. - Create review alternatives. - Identify coverage observations. - Evaluate against rubrics. The catalog defines the configurable scope. Editing guidance does not change fixed tool authority, output contracts, binary evaluation semantics or human approval requirements. ## Save or reset Choose an activity, edit its current guidance and Save. Reset restores inheritance while retaining change history. A concurrent edit is reported instead of silently overwriting newer content. History records who changed the document, when, its scope and its before/after content automatically. Users do not create, name, publish or promote a prompt version. Accepted work captures the effective instructions it uses. A later edit changes future work; it does not rewrite earlier accepted inputs, completed Contributions or existing results. ## Write useful guidance State the desired outcome, relevant context and concrete boundaries. Keep one-time Benchmark questions in the Contribution or Goal rather than permanent project guidance. Allow the agent to interpret the request and select useful tools within its authority. Do not encode every conversation as a fixed classification or mandatory sequence. Review how guidance interacts with the Project Agent Brief, source materials and current standards. A well-written instruction supports reasoning; it cannot turn an unapproved suggestion into a Policy or an absent judgment into a score. ## Related task pages {% related-card-grid title="Related task pages" %} - [Agent Setup](/docs/agent-setup) - [Project Context](/docs/agent-setup/project-context) - [Correctness Governance](/docs/correctness-governance) - [Project Settings](/docs/project-settings) {% /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 %} --- id: agent-setup.project-context title: Project Context summary: Maintain the Project Agent Brief that gives Teammately agents stable, project-wide understanding. kind: reference product_area: agent_setup status: stable updated: 2026-10-30 canonical: /docs/agent-setup/project-context --- # Project Context ## Definition Project Context is the Agent Setup surface that edits the **Project Agent Brief**. The brief gives Teammately agents stable project-wide understanding: what the specialist AI is for, which behavior matters, important constraints, terminology, and other context that should carry across coverage, contribution preparation, case construction, and improvement work. The Project Agent Brief is different from the Project Memo in General settings. The memo is administrative project text and explicitly is not used as prompt or agent context. Put agent-relevant project understanding in Project Context. ## Fields, states, or lifecycle rules - The brief is scoped to the project and reused across benchmark workspaces. - Editing the brief changes future agent context; it does not rewrite completed Contributions, Runs, or Improvement Session history. - The brief provides orientation and constraints, not governed correctness authority. Policies and rubrics remain in Correctness Governance. - Controlling source material belongs in Reference Materials. Summarize stable project intent in the brief and keep source-backed detail in the indexed material. - The brief should state product-specific meaning directly. Avoid copying transient benchmark goals, one expert's unconfirmed opinion, or a temporary candidate hypothesis into permanent project context. ## Writing a useful brief Describe the specialist AI's purpose, users, important domain vocabulary, expected interaction shape, and constraints that affect many workflows. Include explicit boundaries where agents might otherwise make unsafe assumptions. Name controlling authorities without duplicating entire manuals. Review the brief when the product purpose, domain, input architecture, or correctness boundary changes materially. If only one benchmark needs a special objective, put it in that benchmark's setup or Contribution. If only one Improvement Session needs a constraint, put it in the Goal. {% example-demo title="Example: project context boundary" %} The brief states that a procurement assistant supports internal buyers, must distinguish current agreements from expired ones, and should expose uncertainty rather than invent an exception. The current agreements themselves remain indexed Reference Materials. The exact evaluation target for expired-agreement cases belongs to the benchmark and Improvement Session, not the brief. {% /example-demo %} ## Related task pages {% related-card-grid title="Related task pages" %} - [Product Quickstart](/docs/quickstart) - [Reference Materials](/docs/agent-setup/reference-materials) - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) {% /related-card-grid %} --- id: correctness.overview title: Correctness Governance summary: Govern project policies and rubrics, their applicability, linked cases, approval state, and contribution provenance. kind: concept product_area: correctness_governance status: stable updated: 2026-10-30 canonical: /docs/correctness-governance --- # Correctness Governance Correctness Governance is the project-level surface for policies and rubrics. It makes the specialist standards used by expert work and benchmark evaluation inspectable, attributable, and reusable across benchmark workspaces. ## Definition The surface has **Policies** and **Rubrics**. Policy pages describe a behavior rule, its scope, linked examples, approval state, activity, and connected rubrics. Rubric pages define testable evaluation criteria and show how they relate to cases, policies, and evaluation use. Correctness Elicitation is the broader capability that discovers and resolves specialist judgment. Correctness Governance is the product surface that owns the resulting governed project artifacts. Expert Contributions may propose or contribute policies and rubrics, but those artifacts retain their own lifecycle and provenance. ## Decision checkpoint | Need | Inspect or change | Boundary | | --- | --- | --- | | State a reusable behavior rule | Policy | Keep source and expert rationale visible | | Decide where a rule applies | Policy scope and applicability | Do not encode broad intent only in rubric wording | | Make the rule testable | Binary rubric | Define observable pass and fail supporting information | | Connect standards to examples | Linked cases | A linked case does not automatically belong to every benchmark | | Review expert-originated material | Contribution provenance and approval | Contribution output is not silently governed | | Explain evaluation movement | Policy, rubric, case, and version context | Do not rely on an aggregate score alone | ## Policies and rubrics A policy explains what behavior should occur and why. Applicability determines the situations in which the rule controls. A rubric turns that rule into an evaluation question whose result can be traced to observable behavior. Several rubrics may operationalize different parts of one policy, and cases can help demonstrate where each rubric applies. Rubrics should remain atomic enough to interpret. If one rubric simultaneously checks grounding, tone, escalation, and completeness, a failure does not identify the responsible behavior. Split criteria where independent failure supporting information matters. ## Human and agent roles Agents can draft possible wording, surface linked cases, identify proposed applications, and prepare follow-up questions. Experts contribute domain authority through benchmark-scoped work. Project operators inspect and maintain the governed artifacts. Approval history and activity should make the transition between proposal, contribution, and governed state visible. Changing a project-level policy or rubric may affect several benchmarks. Before interpreting a later Run, confirm which benchmark version and standard boundary it used. {% example-demo title="Unsupported compatibility" %} A specialist confirms that compatibility may be claimed only when an authoritative source explicitly supports the exact equipment combination. Correctness Governance records the policy, scopes it to recommendation and validation responses, links representative cases, and defines a binary rubric that passes only when the response cites support or clearly states uncertainty. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Build policies and rubrics](/docs/operating-manual/build-policies-and-rubrics) - [Write Binary Rubrics](/docs/correctness-governance/binary-rubrics) - [Request an Expert Contribution](/docs/expert-contributions/request-contribution) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Policies](/docs/object-model/policies) - [Applicability logic](/docs/object-model/applicability-logic) - [Rubrics](/docs/object-model/rubrics) {% /related-card-grid %} --- id: project-settings.overview title: Project Settings summary: Maintain project understanding, Lemon instructions, Regime, input schema, members, and secret grants in the current settings surface. kind: concept product_area: project_settings status: stable updated: 2026-10-30 canonical: /docs/project-settings --- # Project Settings Project Settings maintains the current configuration shared by a project's Benchmark work. Open the relevant tab for the object you intend to change. ## Definition The settings surface contains **General**, **Project Context**, **Reference Materials**, **Lemon instructions**, **Regime**, **Input Schema**, **Project Members** and **Secrets**. | Setting | Owns | Important distinction | | --- | --- | --- | | General | Project name and Project Memo | Memo is human-facing text, not agent context | | Project Context | Project Agent Brief | Stable project understanding | | Reference Materials | Sources and indexed content | Source refresh does not rewrite the brief | | Lemon instructions | Configured activity guidance | Project override and automatic history | | Regime | Framework, points, gates and guidance | Settings do not approve individual artifacts | | Input Schema | Canonical input and materials | Benchmark planning inherits this contract | | Project Members | User and group access | Membership is separate from task assignment | | Secrets | Project secret access and grants | Values are not Run metadata or source code | ## Change boundaries A project setting can affect future work across multiple Benchmarks. Accepted tasks and Runs retain the inputs, settings and instructions they captured. Saving current settings does not rewrite historical results. Changes record their actor, scope, time and before/after content automatically where the owning setting provides history. Users do not create or publish a separate settings version to make an edit take effect. ## Operating sequence Inspect the current value and its scope. Make the intended edit, save through the owning control and read its authoritative result. Resolve a concurrent-change response without discarding another operator's work. Use Input Schema to change required Case materials. Use Regime to configure point interpretation. Use Lemon instructions for activity guidance and the Project Agent Brief for stable product meaning. ## Related work Benchmark Datasets owns selected membership and Snapshots. Coverage Design owns input requirements and adoption decisions. Expert Contributions owns a request, its accepted plan and attributable judgments. Run details preserve recorded execution metadata. They do not create a current Run Metadata settings tab. ## Related reference pages {% related-card-grid title="Related reference pages" %} - [General Project Settings](/docs/project-settings/general) - [Project Context](/docs/agent-setup/project-context) - [Reference Materials](/docs/agent-setup/reference-materials) - [Lemon Instructions](/docs/project-settings/lemon-instructions) - [Regime Settings](/docs/project-settings/regime) - [Project Input Schema](/docs/project-settings/input-schema) - [Project Members](/docs/project-settings/project-members) - [Project Secrets](/docs/project-settings/secrets) {% /related-card-grid %}