Teams & Workspaces

Create and select workspaces, manage bounded invitations, memberships and roles, and administer versioned tenant configuration, domains, entitlements, and publication revisions without crossing tenant or authority boundaries.

BUSINESS CASES

Where this module fits

workspace onboarding
team membership lifecycle
active workspace selection

PRIMARY CONSUMERS

Who integrates it

workspace owners
team administrators
collaboration agents

PREREQUISITES

What must exist first

tenant membership
owner or administrator role for team mutations
admin:tenants scopes and fresh purpose-bound step-up for tenant configuration mutations
current membership, tenant, revision, domain, and entitlement versions

RECOMMENDED WORKFLOW

Compose the module safely.

01
create or select an authenticated workspace
02
invite members with a bounded predefined role and accept through the invitation owner
03
read the privacy-minimized active roster before changing or revoking membership
04
review, change, or revoke membership with version and last-owner protections
05
draft, review, publish, or revert tenant configuration as separate versioned stages
06
verify domain possession before any separately owned routing or certificate activation

AGENT INTEGRATION

Machine-use boundaries

Derive tenant and workspace context from authenticated membership; never accept caller-selected owner, role authority, actor, or cross-tenant resource identifiers.
Use optimistic versions and never silently overwrite concurrent membership, role, revision, domain, or entitlement changes.
An invitation is not membership; a draft is not reviewed or published; a registered domain is not verified or routed; an entitlement is not a bearer scope or operational authority.
Preserve last-owner, administrator access, recovery, billing, domain, and dependent-resource safety when changing or removing configuration.
Tenant configuration and entitlements cannot enable frozen trading controls, matching, prediction execution, ingress, publisher activity, market status, or traffic.
Treat legacy POST workspace mutation aliases as bodyless 501 migration markers and use their implemented PUT, DELETE, or invitation replacements from live OpenAPI.
The active roster exposes opaque membership and profile references, role, version, status, and timestamps only; it is not an email or global Identity directory and invitation state remains a separate lifecycle.
Every workspace mutation requires the live OpenAPI Idempotency-Key and HTTP Message Signature contract. Reuse a key only for the byte-equivalent logical retry and re-read canonical state after a 409 or ambiguous result.

Register only production-listed routes as executable tools, and re-fetch the deployed OpenAPI before generating or sending a request. Source-ready routes awaiting deployment are preparation references; planned contracts are non-executable.

MODULE CONTRACTS

Every mapped endpoint

Each operation states whether its request shape is authoritative in OpenAPI, reviewed as a planning profile, or intentionally left as an outline pending an owner schema.