# Project Settings
Generated: 2026-09-13T04:33:48.739Z
Source build: local
Canonical docs: https://teammately.ai/docs
---
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: 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.input-schema
title: Project Input Schema
summary: Define the canonical input architecture, case-material fields, and accepted artifact formats for project cases.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/input-schema
---
# Project Input Schema
## Definition
Project Input Schema is the project-managed contract for future cases. It declares the primary input architecture, optional structured-input schema, named case-material fields, and artifact families or file extensions the project accepts.
The active architectures are **plain text**, **chat**, and **structured**. The schema is a project singleton rather than a versioned benchmark object. When no setting exists, the default accepts one plain-text user message and no case materials or artifacts.
## Fields, states, or lifecycle rules
- `architecture` is `plain_text`, `chat`, or `structured`.
- Structured architecture requires a bounded `structuredInputSchema`.
- `caseMaterialSchema` is a closed, flat object. Each material key has a label, optional description, required flag, type, and any accepted artifact rules.
- Material keys use lowercase letters, digits, and underscores, start with a letter, and remain flat.
- `acceptedArtifacts` declares project-level artifact families. Supported families are image, document, tabular, presentation, source text, and audio.
- A case-material artifact rule must be a subset of the artifact families admitted at the project root.
- Saving a new schema governs future case validation. Operators should inspect existing cases before making a change that would make current content invalid.
## Canonical case content
The primary case payload is `content.input`. Optional supporting values and artifacts live in `content.case_materials`. The product renders `record_content.case_view` so people and execution adapters can inspect the canonical content consistently; that view is a projection rather than an alternate authoring contract.
Static support passed to a Harness uses `case_material_refs`. An executable or queryable environment uses an optional `world_instance_ref`. Do not collapse static documents, images, or values into the world boundary merely because a candidate consumes them during a Run.
{% example-demo title="Example: structured support case" %}
A project selects structured input with `question` and `customer_tier` properties. It declares a required `policy_document` case material that accepts PDF documents and an optional `account_history` tabular material. A case is valid only when its structured input matches the schema and the required document is present in the accepted format.
{% /example-demo %}
## Source confidence
Code-backed: the active settings route and backend validator define the input architectures, closed case-material schema, artifact families, defaults, and canonical case paths. This page explains the product contract without presenting internal handlers as a public API.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Project Settings](/docs/project-settings)
- [Product quickstart](/docs/quickstart)
- [Work with cases](/docs/assets/cases)
- [Design Review Screen](/docs/assets/review-screens)
{% /related-card-grid %}
---
id: project-settings.project-members
title: Project Members
summary: Grant or remove user and group access to a project while keeping task assignment and artifact governance separate.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/project-members
---
# Project Members
## Definition
Project Members manages which workspace users and groups can access a project. A grant names a principal of type **USER** or **GROUP**; removing the grant removes that project-level access path.
Membership is not the same as selecting an expert for a Contribution, assigning a review task, or approving an artifact. Those workflows add scoped responsibility inside an already accessible project.
Before removing access, check whether the person or group owns active Contribution work or operational follow-up. Reassign that work first; this page does not define what historical records remain visible after access changes.
## Fields, states, or lifecycle rules
- A grant targets a user or group principal.
- Adding a grant creates a project access path.
- Removing a grant removes that current Project access path.
- Effective access can remain through another user, group, or workspace-level path.
## Manage access
1. Open **Project Settings → Project Members**.
2. Review existing principals and whether each grant belongs to a user or group.
3. Add the smallest appropriate principal. Prefer a managed group when access follows a durable team responsibility.
4. Before removing a grant, check active Contributions, reviews, and operational ownership that may need reassignment.
5. Confirm the resulting member list and test the intended product path through ordinary authorization.
Group access follows the group relationship managed by the workspace; it should not be duplicated as many individual grants without an operational reason. A user can also have more than one access path, so removing one grant may not remove all effective access.
> Access boundary
>
> Grant the smallest appropriate project scope. Do not copy credentials or sensitive material into project content as a substitute for access control.
Project access does not grant secret values automatically. Harness secret grants remain explicit. Contribution selection also remains separate: an expert needs the applicable project access path and a scoped Contribution before completing assigned work.
This page makes no retention-period or post-removal visibility guarantee. Historical attribution and record access are governed by the records and permissions the current product exposes at the time they are inspected.
{% related-card-grid title="Related governance" %}
- [Roles and permissions](/docs/governance/roles-and-permissions)
- [Reviewer and project access](/docs/governance/reviewer-and-project-access)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
{% /related-card-grid %}
## Source confidence
Code-backed: the active members and project-permissions routes expose user and group grants and removal. Workspace-wide role administration remains a separate governance surface.
---
id: project-settings.regime
title: Regime Settings
summary: Inspect and publish the project scoring Regime that governs future Benchmark Versions.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/regime
---
# Regime Settings
## Definition
Regime Settings define how approved and applicable Rubrics contribute to Case and Benchmark results. The Regime is part of the project contract, but its published version is pinned into later Benchmark Versions so historical evaluation evidence remains interpretable.
The settings surface shows the Project's locked framework, its decision rule, what the framework is suited for, and which scoring controls administrators can configure. A framework is not a Policy or Rubric; it determines how those governed artifacts are interpreted and aggregated for evaluation.
## Fields, states, or lifecycle rules
- The framework is locked for an existing Project. Other framework choices can be available when creating a new Project.
- Depending on the framework contract, administrators can configure Case aggregation, score range, penalty policy, Rubric role assignment, safe custom formulas, and an Importance scale.
- A custom formula is validated and stored as typed configuration; it is not executable code.
- Editing creates unpublished scoring changes. **Publish new Version** creates an immutable Regime Version after validation and concurrency checks.
- New drafts and finalized Benchmark Versions retain the Regime Version they were created or finalized with. Publishing a later version does not rewrite existing plans, Runs, or results.
- Published version history shows prior configurations and can show which open drafts or Benchmark Versions use a version.
- A concurrent publication requires the administrator to review the latest version before publishing retained edits.
## Configure safely
Review the framework decision rule before changing scoring behavior. Confirm that the desired aggregation, score range, penalties, and Importance semantics match the Policies and Rubrics that will be evaluated. Publish only after the resulting version can be explained to someone reading a future Benchmark result.
Do not use Regime Settings to change the meaning of a Policy or Rubric. Change those governed artifacts through Correctness Governance, then create or evaluate the appropriate versioned benchmark evidence.
{% example-demo title="Example: preserving historical scoring" %}
An administrator changes the score range and publishes Regime Version 4. New Benchmark Versions pin Version 4, while an existing finalized Benchmark Version continues to report under Version 3. The administrator can inspect both configurations and their usage without treating the new scoring choice as a rewrite of old results.
{% /example-demo %}
## Source confidence
Code-backed: the Project Settings Regime panel exposes locked framework guidance, scoring configuration, validation, immutable publication, concurrent-publication recovery, and version history. The project API exposes framework discovery, current Regime reads, publication, history, and version usage.
## Related task pages
{% related-card-grid title="Related task pages" %}
- [Configure Project Settings](/docs/project-settings)
- [Build Policies and Rubrics](/docs/operating-manual/build-policies-and-rubrics)
- [Run a benchmark evaluation](/docs/benchmark-evaluations/run-evaluation)
{% /related-card-grid %}