# General Project Settings
Generated: 2026-09-13T04:34:30.041Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
id: project-settings.general
title: General Project Settings
summary: Manage the project name and Project Memo without confusing descriptive metadata with agent context.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/general
---
# General Project Settings
## Definition
General settings contain the project **Name** and **Project Memo**. The name identifies the project in Teammately. The memo is project-level descriptive metadata for people working in the project.
> Project Memo is not agent context
>
> The Project Memo is not injected into prompts and does not replace Project Context, Reference Materials, or Review Screens. Put agent-facing operating context in Agent Setup.
Use the memo for a concise human-readable purpose, ownership note, or operating reminder. Avoid secrets and avoid relying on it for behavior that must be reproducible in a Harness or evaluation.
## Fields, states, or lifecycle rules
- Name is the editable project identifier shown to people.
- Project Memo is human-facing descriptive text and has no prompt-injection state.
- Saving either field changes current project metadata without versioning historical benchmark evidence.
## Choose the right surface
| Information | Put it in | Reason |
| --- | --- | --- |
| Human-facing project purpose or ownership note | Project Memo | Describes the project without affecting behavior |
| Domain and operating context for agents | Project Context | Enters the governed agent-facing setup |
| Contribution-specific review behavior | Expert Contribution | Keeps behavior visible in the scoped request |
| Source documents and connected knowledge | Reference Materials | Preserves source identity and indexing state |
| Candidate implementation or prompt logic | Harness | Gives the executable candidate an exact Version |
| Scoring behavior for future Benchmark Versions | Regime | Keeps the evaluation contract versioned and inspectable |
Changing the project name updates how people locate the project; it does not create a new Benchmark Version. Changing the memo likewise does not invalidate a Dataset Snapshot or alter historical Runs. If a memo change represents a real change in benchmark purpose, update the governed coverage, evaluator, and versioned evidence surfaces separately.
{% example-demo title="Example: memo versus context" %}
The memo says that the project is owned by the support automation team and covers policy-grounded replies. Project Context explains the product domain and operating constraints to Teammately agents. A grounding rule lives in the candidate Harness or governed policy, not in the memo.
{% /example-demo %}
{% related-card-grid title="Agent-facing configuration" %}
- [Configure Project Context](/docs/agent-setup/project-context)
- [Manage Harnesses](/docs/assets/harnesses)
{% /related-card-grid %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Configure Project Context](/docs/agent-setup/project-context)
{% /related-card-grid %}
## Source confidence
Code-backed: the active General settings route defines the editable name and Project Memo and explicitly distinguishes the memo from prompt context.
---
id: project-settings.overview
title: Project Settings
summary: Configure the project identity, evaluation Regime, case input contract, and project members.
kind: concept
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings
---
# Project Settings
Project Settings is a floating project-level surface rather than a benchmark workspace. Its current tabs are **General**, **Regime**, **Input Schema**, and **Project Members**.
| Setting | Governs | Does not replace |
| --- | --- | --- |
| General | Project name and Project Memo | Agent Setup context or instructions |
| Regime | How approved and applicable Rubrics contribute to future Benchmark Versions | Policies, Rubrics, or already-published Benchmark evidence |
| Input Schema | Canonical case input and material contract | A benchmark dataset snapshot |
| Project Members | User and group access to this project | Contribution task assignment |
Changes are project-scoped and may affect future work across multiple benchmarks. Treat input-contract and access changes as governance decisions, and preserve exact versions and snapshots wherever historical evidence depends on them.
## Change boundaries
Project Settings is intentionally separate from Agent Setup and benchmark workspaces. A settings change can influence what future work accepts or displays, but it does not silently rewrite a saved Harness Version, Dataset Snapshot, Contribution, or Run. When a project-wide contract changes, inspect downstream readiness and create new versioned evidence where the product workflow requires it.
Input Schema deserves the most caution because future Case validation follows it. Before tightening a required material or changing architecture, identify existing Cases that may no longer conform. Regime changes create a new immutable Regime Version for future Benchmark Versions; existing Benchmark Versions, Runs, and results retain their published Regime Version. Project Members affects access, not authorship or task history.
## Operating sequence
1. Set a clear project name and human-facing memo.
2. Review the locked Regime and publish a new version only when the scoring contract should change for future Benchmark Versions.
3. Define the Input Schema before importing or constructing substantial Case evidence.
4. Grant users and groups the project access needed for their role.
5. Revisit settings when the project contract changes, then check Assets, benchmarks, and active Contributions for downstream impact.
{% example-demo title="Example: adding a required document" %}
A project decides every future Case must include a controlling policy document. The operator updates Input Schema only after auditing current Cases. Existing Dataset Snapshots remain historical evidence; corrected live Cases enter a new Snapshot. The Project Memo may explain the ownership decision, but it does not enforce the material requirement.
{% /example-demo %}
## Relationship to governance
Workspace administration controls the wider account boundary. Correctness Governance owns Policies and Rubrics. Project Settings should therefore express project contracts and access, not become a catch-all place for evaluator rules, secret values, or informal candidate configuration.
{% related-card-grid title="Project settings" %}
- [General settings](/docs/project-settings/general)
- [Regime settings](/docs/project-settings/regime)
- [Project Input Schema](/docs/project-settings/input-schema)
- [Project Members](/docs/project-settings/project-members)
{% /related-card-grid %}
{% related-card-grid title="Connected workspaces" %}
- [Agent Setup](/docs/agent-setup)
- [Assets](/docs/assets)
- [Benchmark Datasets](/docs/benchmark-datasets)
{% /related-card-grid %}
## Source confidence
Code-backed: the active Project Settings surface defines the General, Regime, Input Schema, and Project Members tabs. Reference Materials is documented under Agent Setup because it supplies governed project knowledge rather than these four settings contracts.
---
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-08-22
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 Contract.
{% 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 %}
## Source confidence
Code-backed: the active Agent Setup Project Context route renders the Project Agent Brief editor. The distinction from General settings is supported by the current project settings UI.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Product quickstart](/docs/quickstart)
- [Use Reference Materials](/docs/agent-setup/reference-materials)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}