# Workspaces, projects, and target systems Generated: 2026-09-13T04:38:59.827Z Source build: local Canonical docs: https://teammately.ai/docs --- id: object-model.workspaces-projects-systems title: Workspaces, projects, and target systems summary: Model organizational boundaries, product boundaries, and the AI system being governed. kind: reference product_area: object_model status: stable updated: 2026-09-07 canonical: /docs/object-model/workspaces-projects-and-target-systems --- # Workspaces, projects, and target systems ## Definition Workspaces, projects, and target systems define where organizational access, product-specific correctness work, and the AI behavior under evaluation are separated. A workspace groups people and administration; a project holds the cases, standards, coverage, and benchmark evidence for a specific target behavior. Use this reference when a reader needs to know whether an artifact belongs to an organization boundary, a project boundary, or the target system being evaluated. ## Fields, states, or lifecycle rules - Workspace boundaries should not be used to infer project-level correctness decisions. - Project boundaries keep cases, policies, rubrics, coverage, benchmark versions, and review context tied to a specific target behavior. - Target-system identity matters for benchmark-level run metadata and comparison interpretation. - Cross-project reuse should not imply cross-project approval. - This page does not make billing, tenancy, deployment, or compliance claims. ## Related objects Workspaces, projects, and target systems should be read with [Product map](/docs/getting-oriented/product-map), [Product boundaries](/docs/introduction/product-boundaries), [Permissions](/docs/reference/permissions), and [Run metadata](/docs/benchmark-evaluations/run-metadata). {% example-demo title="Workspaces, projects, and target systems boundary" %} Scenario: The same company evaluates a support assistant and an internal policy-search assistant. Project boundary: Each assistant has its own cases, policies, rubrics, benchmark versions, and benchmark-level run metadata. Interpretation: A passing benchmark in the support project should not imply the policy-search assistant has approved evidence. {% /example-demo %} ## Source confidence Code-backed: Project and workspace types establish organization and Project identity; member settings expose Project participation; benchmark Run presentation identifies the evaluated target boundary. These sources do not establish billing, deployment, or tenancy guarantees. ## Related task pages {% related-card-grid title="Related task pages" %} - [Workspaces and projects](/docs/concepts/workspaces-projects) - [Product map](/docs/getting-oriented/product-map) - [Product boundaries](/docs/introduction/product-boundaries) - [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: orientation.product-map title: Product map summary: Navigate Teammately across workspace entry points, project foundations, benchmark workspaces, expert contribution UI, and administration. kind: concept product_area: introduction status: stable updated: 2026-09-07 canonical: /docs/getting-oriented/product-map --- # Product map Teammately separates reusable project foundations from benchmark-scoped work. The Main UI uses the selected project and benchmark to route operators to the right scope. Experts receive a focused Expert contribution UI. Admin Console owns organization-level controls, while AI-assisted background work prepares and coordinates bounded tasks. > Surface routing > > Before changing an artifact, identify its scope. Project foundations can affect several benchmarks; dataset selection, Contributions, Evaluations, and Improvement Sessions belong to a selected benchmark or benchmark version. ## Definition The **Main UI** begins at Project Home and groups project-level work into Correctness Governance, Coverage Facets, Assets, Agent Setup, and Project Settings. After a benchmark is selected, its workspace exposes Benchmark Overview, Benchmark Datasets, Coverage Management, Expert Contributions, Benchmark Evaluations, and Improve. The **Expert contribution UI** presents one Contribution and its form, chat, interview, case-review, checkpoint, waiting, and completion states. The expert does not need the full project navigation to supply attributable judgment. The **Admin Console** contains organization administration such as members, groups, roles, domain controls, integrations, and other code-backed administrative surfaces. Public docs keep detailed security, billing, retention, and compliance claims outside the boundary unless separately verified. **AI-assisted background work** can index reference material, prepare contributions, suggest coverage or standards, construct cases, run evaluations, and coordinate candidate exploration. Its outputs retain the authority of the owning artifact and workflow. ## Decision checkpoint | Work | Scope | Surface | | --- | --- | --- | | Project purpose and knowledge | Project | Agent Setup | | Policies and rubrics | Project | Correctness Governance | | Dimensions, Topics, and construction patterns | Project | Coverage Facets | | Reusable Cases and Harnesses | Project | Assets | | Input architecture | Project | Project Settings | | Benchmark-level run fields | Benchmark | Benchmark Evaluations | | Selected Cases, representation, and snapshots | Benchmark | Benchmark Datasets | | Coverage setup, Stories, Case Review, and Foundry | Benchmark | Coverage Management | | Specialist requests and contributed artifacts | Benchmark | Expert Contributions | | Runs, results, Compare, and Arena | Benchmark version | Benchmark Evaluations | | Goal Contracts, candidates, and frontier | Benchmark version | Improve | ## How selection affects navigation Project surfaces require a project. Benchmark surfaces also require a benchmark, and Evaluations or Improve may resolve the current benchmark version. If a destination is unavailable, confirm the current selectors before assuming that the feature or data is missing. Project folders and search help users move across a larger workspace, but they do not change artifact ownership. Search results and creation actions should preserve the selected project or benchmark scope. {% surface-map title="Teammately product surfaces" %} {% /surface-map %} {% example-demo title="Route a new rubric need" %} An evaluation exposes inconsistent handling of expired agreements. The operator uses the benchmark workspace to request an Expert Contribution with the failed cases. The expert works in the focused contribution UI. The resulting rubric is reconciled in Correctness Governance at project scope, then included in a later benchmark version and evaluation. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [Task index](/docs/operating-manual/task-index) - [Operating Teammately end to end](/docs/getting-oriented/operating-teammately-end-to-end) - [Product quickstart](/docs/quickstart) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Key objects and relationships](/docs/getting-oriented/key-objects-and-relationships) - [User roles](/docs/getting-oriented/user-roles) - [Product boundaries](/docs/introduction/product-boundaries) {% /related-card-grid %} ## Source confidence Code-backed: current navigation and active project, benchmark, Contribution, and administration routes establish the scope and labels described here. --- id: intro.product-boundaries title: Product boundaries summary: Understand what Teammately owns across correctness specification, benchmark development, evaluation, and improvement. kind: concept product_area: introduction status: stable updated: 2026-09-07 canonical: /docs/introduction/product-boundaries --- # Product boundaries Teammately owns the correctness system that connects specialist judgment to deliberate benchmark coverage, executable standards, constructed cases, evaluation evidence, and improvement history. This page distinguishes that system from adjacent inputs and downstream responsibilities. > Adjacent systems are inputs > > Logs, traces, source repositories, model endpoints, coding environments, and external evaluation results can supply material or receive work. Their presence does not change the Teammately ownership boundary: Teammately governs the connected correctness artifacts and the evidence produced from them. ## Definition The product boundary follows artifacts and authority. Teammately can index project knowledge, prepare an expert contribution, materialize an accepted policy or rubric, construct a case, execute an evaluation through a managed harness, and coordinate an Improvement Session. It preserves which inputs, versions, settings, and human decisions produced the resulting evidence. Customer teams own the AI system outside that evidence graph and the action taken afterward. Teammately can prepare a scoped package for an external coding worker, but it does not claim private work performed outside the product. It can show benchmark evidence, but it does not turn that evidence into an automatic downstream decision. ## Decision checkpoint | Area | Teammately owns | Boundary | | --- | --- | --- | | Project knowledge and agent context | Materials, Indexed Reference, Project Context, and Contribution-scoped agent behavior | Reference material is not automatically a governed policy or rubric | | Expert work | Contribution scope, tasks, checkpoints, attributable responses, and contributed artifacts | Agent preparation does not substitute for the expert's judgment | | Cases and worlds | Canonical case input, case materials, generated artifacts, and verified world references | Static materials and executable environments remain distinct | | Evaluation | Benchmark Versions, saved Harness Versions, settings, Runs, responses, Rubric results, and comparisons | A score alone does not explain correctness; execution traces are not currently exposed | | Improvement | Goal Contracts, candidates, evaluation receipts, frontiers, and chronology | External worker activity is represented only when returned through the defined contract | | Downstream action | Inspectable correctness evidence and review context | The customer decides what operational action follows | ## Human and agent authority AI agents scale preparation and exploration. They can organize source material, propose coverage structure, draft possible standards, generate cases, evaluate candidates, and suggest improvement directions. The owning surface determines when an artifact becomes durable or governed. An agent proposal does not silently acquire expert authority. Expert Contributions make this boundary explicit. The product can prepare focused questions and relevant evidence, while the domain specialist supplies the judgment. Correctness Governance records policies and rubrics as governed project assets. Improvement Sessions can branch candidate hypotheses, but retained candidates require observable evaluation evidence. ## Data and execution boundary Project Input Schema controls the accepted shape of case input and materials. Static context remains part of case content or case-material references. An executable or queryable environment uses a world reference and follows a separate runtime boundary. Public docs describe the behavior visible through stable product surfaces; they do not promote internal storage or service structures into customer-facing contracts. Similarly, the presence of Harness Assets and managed Runs does not imply that Teammately owns a customer's model registry, production telemetry, or deployment system. A harness is the executable candidate boundary used by a benchmark evaluation. {% example-demo title="External coding worker" %} An Improvement Session starts from failed grounding Cases and a confirmed Goal Contract. Teammately prepares a scoped package for a coding worker with the pinned target and evidence. The worker's private activity is outside the product boundary. A returned Harness Version and canonical evaluation request become observable candidates; their Rubric results enter the session record, while Improve may add a safe narrated trajectory of observable session activity. {% /example-demo %} ## Related workflows {% related-card-grid title="Related workflows" %} - [The correctness lifecycle](/docs/introduction/correctness-lifecycle) - [Start an Improvement Session](/docs/improve/start-improvement-session) - [Use Reference Materials](/docs/agent-setup/reference-materials) {% /related-card-grid %} ## Related reference pages {% related-card-grid title="Related reference pages" %} - [Human Approval Boundaries](/docs/governance/human-approval-boundaries) - [What AI Features Can and Cannot Do](/docs/governance/what-ai-features-can-and-cannot-do) - [Project Input Schema](/docs/project-settings/input-schema) {% /related-card-grid %} ## Source confidence Doctrine-backed: this page states product ownership and authority boundaries. Exact UI and execution behavior is delegated to linked code-backed pages.