---
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.