# IDs and keys Generated: 2026-09-13T04:32:40.536Z Source build: local Canonical docs: https://teammately.ai/docs --- id: reference.ids title: IDs and keys summary: Understand the identifiers used across Teammately projects, records, benchmarks, runs, policies, and rubrics. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/ids --- # IDs and keys ## Definition IDs and keys identify Teammately objects across projects, records, cases, benchmarks, runs, policies, rubrics, and administration surfaces. They matter because review context and benchmark evidence are only reproducible when the referenced objects are unambiguous. Use this reference when a note, run, comparison, or troubleshooting path depends on matching the same project, case, standard, benchmark version, or candidate boundary. ## Fields, states, or lifecycle rules - IDs should preserve which object a page, result, or review note is talking about. - Keys and identifiers may appear in URLs, metadata, manifests, admin surfaces, or internal source refs. - A stable ID does not imply that a public API, export format, or integration contract exists. - Review notes should name object boundaries, not only human-readable titles, when reproducibility matters. - Do not expose secrets or infer API-key behavior beyond source-backed admin pages. ## Related objects IDs and keys should be read with [Workspaces and projects](/docs/concepts/workspaces-projects), [Assets](/docs/assets), [Run Metadata](/docs/benchmark-evaluations/run-metadata), and [Permissions](/docs/reference/permissions). {% example-demo title="IDs and keys boundary" %} Scenario: A comparison note says the candidate improved but does not identify the benchmark version or candidate run. ID boundary: The note should identify the benchmark version, run, candidate metadata, and changed artifact if those references are available. Interpretation: Without those identities, the comparison is weak evidence even if the score is visible. {% /example-demo %} ## Source confidence Code-backed: current Project, user, workspace, Benchmark, Policy, and Rubric types show distinct opaque identifiers for those product objects. The reference does not assert that every internal identifier is accepted by a customer-facing API or safe to construct. ## Related task pages {% related-card-grid title="Related task pages" %} - [Workspaces and projects](/docs/concepts/workspaces-projects) - [Permissions](/docs/reference/permissions) - [Assets](/docs/assets) - [Product quickstart](/docs/quickstart) - [Task index](/docs/operating-manual/task-index) {% /related-card-grid %} --- id: concepts.workspaces-projects title: Workspaces and projects summary: Learn how Teammately organizes teams, projects, product goals, and access boundaries. kind: concept product_area: object_model status: stable updated: 2026-09-07 canonical: /docs/concepts/workspaces-projects --- # Workspaces and projects ## Definition The Workspace is the organization-level container. A Project is the operating boundary for one body of correctness work: its Project Agent Brief, Coverage Facets, Cases, Policies, Rubrics, Harnesses, Agent Setup, Project Settings, and Benchmarks. ## Why it matters The distinction matters because Workspace membership and Project participation are not interchangeable. A person can belong to the organization without having access to every Project, and a role label must not be treated as proof of a specific permission. ## Where it appears in the product Project Settings exposes General configuration, Regime, Input Schema, and Project Members. Organization-level administration belongs to the Admin Console. Benchmark work remains nested inside the selected Project and reuses that Project's governed objects. ## Artifacts it affects The boundary affects navigation, identifiers, membership, permissions, Project Agent Brief generations, Cases, governed standards, Harnesses, Benchmarks, Runs, and Contributions. Moving or copying artifacts between Projects is not implied by shared Workspace membership. ## Boundary check When a user cannot reach an object, confirm the Workspace, Project ID, Project membership, and object-specific assignment separately. When an artifact appears reusable across Projects, verify its source context, owner, and correctness boundary before recreating it. Shared organizational membership is never evidence that two Projects use the same Cases, standards, or Benchmark Versions. {% example-demo title="Same policy shape, different projects" %} One Workspace contains a billing-assistant Project and a security-assistant Project. The teams may use similar Rubric-writing practices, but their Project Agent Briefs, Cases, Policies, Harnesses, reviewers, and Benchmark evidence remain project-scoped. A user who can administer the billing Project is not assumed to have the same access in the security Project. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Configure Project settings](/docs/project-settings) - [Manage Project Members](/docs/project-settings/project-members) - [Understand organization administration](/docs/admin-console) - [Troubleshoot permissions](/docs/troubleshooting/permissions) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [IDs and keys](/docs/reference/ids) - [Permissions](/docs/reference/permissions) - [Workspaces, Projects, and target systems](/docs/object-model/workspaces-projects-and-target-systems) - [Project Context](/docs/agent-setup/project-context) {% /related-card-grid %} ## Source confidence Code-backed: Workspace and Project types establish the container boundary; Project Settings, Members, and Permissions expose the current project-scoped configuration and access surfaces. Organization-level behavior is intentionally left to the separately bounded Admin Console documentation. --- id: reference.permissions title: Permissions summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access. kind: reference product_area: reference status: stable updated: 2026-09-07 canonical: /docs/reference/permissions --- # Permissions ## Definition Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow. This reference does not turn role labels into a complete public permission matrix. Exact permission behavior should stay tied to source-backed pages and the admin or project surfaces that expose it. ## Fields, states, or lifecycle rules - Project access affects cases, standards, coverage, benchmark work, and project settings. - Reviewer access affects assigned expert work and reviewer-facing surfaces. - Organization administration affects members, groups, roles, security controls, API keys, and integrations. - Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts. - Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference. ## Related objects Permissions should be read with [Admin Console](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and project access](/docs/governance/reviewer-and-project-access). {% example-demo title="Permissions boundary" %} Symptom: A reviewer can sign in but cannot complete assigned case review. Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context. Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark evidence. {% /example-demo %} ## Source confidence Code-backed: Project, user, and workspace types plus Project Permissions and Members surfaces support the user-facing boundaries described here. They do not form an exhaustive authorization matrix; assignment, organization administration, and object approval remain separate product states. ## Related task pages {% related-card-grid title="Related task pages" %} - [Admin Console](/docs/admin-console) - [Workspaces and projects](/docs/concepts/workspaces-projects) - [Permissions troubleshooting](/docs/troubleshooting/permissions) - [Expert UI](/docs/integrations/reviewer-workspace) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} --- id: assets.cases title: Cases summary: Understand canonical project cases, their input and materials, and how they become members of benchmark datasets. kind: reference product_area: assets status: stable updated: 2026-08-22 canonical: /docs/assets/cases --- # Cases ## Definition A Case is a project-level situation used for expert contribution, benchmark coverage, or candidate evaluation. It has canonical input content and may include declared supporting materials. Cases live in the Assets pool and can be selected into one or more benchmark datasets. The Project Input Schema determines how the primary input and materials are represented. A benchmark snapshot determines which selected cases belong to one versioned evidence boundary. ## Fields, states, or lifecycle rules - Canonical primary input is stored under `content.input`. - Optional supporting values or artifacts are stored under `content.case_materials` according to the project's declared keys. - `record_content.case_view` is a rendered projection used for inspection and delivery; it is not a second editable payload. - Inputs can use plain-text, chat, or structured architecture as configured by the project. - Materials can include admitted artifact families and must satisfy any required-field and file-extension rules. - A project Case is not automatically part of every benchmark. Benchmark Datasets owns selection and snapshots. - Generated or imported Cases should be reviewed for clarity, source authority, and schema conformance before they are trusted as benchmark evidence. - Static case materials and executable Worlds remain separate. A document supplied to a Harness does not become a world merely because it affects execution. ## Case identity and change Treat the persisted case identity as opaque. Do not construct IDs in client code or documentation. When case content changes materially, benchmark interpretation must use a snapshot or version boundary that makes the selected content clear. Responses produced by a Harness are evaluation outputs attached to a Run. They are not the primary case input. Expert-authored acceptable examples can inform standards or contribution work, but the current evaluation contract should remain explicit about which candidate produced each response. {% example-demo title="Example: multimaterial case" %} A chat case asks whether an exception applies. Its required `current_policy` PDF and optional `account_history` table are stored as case materials admitted by Project Input Schema. The rendered case view presents the conversation and both materials. A benchmark snapshot selects the case, and a Run records the evaluated Harness response separately. {% /example-demo %} ## Source confidence Code-backed: the active Assets Cases route and case-content services define canonical input, case materials, and the rendered case view. Public import or export APIs are outside this reference unless separately documented. ## Related task pages {% related-card-grid title="Related task pages" %} - [Configure Project Input Schema](/docs/project-settings/input-schema) - [Work with Benchmark Datasets](/docs/benchmark-datasets) - [Manage benchmark coverage](/docs/coverage-management) {% /related-card-grid %}