Organizations, Teams, and Projects

Weaver separates tenant ownership, reusable access groups, and training scope. The hierarchy is:

Organization
├─ organization members (admin | member)
├─ teams (reusable member groups)
└─ projects (access and cost-attribution boundaries)
   └─ sessions
      └─ training runs
         └─ checkpoints

Organization

An organization is Weaver's highest tenant, membership, and billing boundary. A user sees only organizations where they have an explicit membership; a Weaver system role does not grant implicit access to another organization's data.

On first use, Weaver creates a personal organization and a default project when the user has no existing scope. Organization display names are case-insensitively unique across Weaver, and organization slugs are globally unique. Concurrent duplicate-name creation returns 409. Scope resolution retains 409 ambiguous_scope_reference as a fail-safe for any legacy duplicate data instead of guessing.

Organization roles are admin and member. See Roles and Permissions for the exact management boundary.

Team

A team is an organization-local group of members used to reuse project grants. It is not a child tenant, billing account, or owner of training data.

An organization admin can:

• create, rename, and delete a team;
• add an existing organization member by email;
• invite a new user into the organization and optionally assign that invitation to a team;
• grant the team access to one or more projects.

Deleting a team removes its memberships and project grants. It does not delete projects, sessions, training runs, checkpoints, or historical usage. A team cannot contain a user from another organization and cannot receive a project grant from another organization.

Project

A project is the permission and cost-attribution boundary inside an organization. Project names and slugs are case-insensitively unique within their organization. A user may gain access directly or through a team; when multiple grants exist, Weaver uses the strongest project role (manager, member, then viewer).

Project selection scopes training Sessions and Usage & Billing. Organization-wide pages such as Members, Teams, API Keys, Supported Models, and Help do not use the project selector.

Project access permits reading the project's sessions, training runs, and checkpoints according to the grant. Live operations remain creator-only: sharing a project does not let another user heartbeat, train, sample, or change the lifecycle of an existing user's session.

Archive instead of destructive deletion

Deleting a non-default project archives it. Archived projects:

• remain attached to historical sessions, runs, checkpoints, and usage;
• are hidden from the default active-project list;
• can be included by administrative API reads with include_archived=true;
• are read-only and reject new sessions with 409 project_archived.

This preserves immutable training history without keeping an inactive project available for new work. The default project cannot be archived.

Choosing a scope

The Console switches organizations from the user menu and shows the project selector only on training and billing surfaces. The Python SDK can use canonical IDs, globally unique organization slugs, organization display names, and organization-local project slugs or names. See SDK Scope Selection.