Settings

Settings is the workspace administration hub, reached from the bottom of the sidebar. The landing page shows where you are — the workspace name, its URL slug, and your own role — and links out to the administration surfaces: Account, Members, and Billing. Billing has no sidebar entry of its own; you reach plan, usage, and capacity details from here (see plans for what each plan includes).

Account

Account settings are personal and available to every member regardless of role. Here you manage:

• Profile — your display name.
• Sign-in — the page shows how you sign in (email and password, Google, GitHub, or a combination). You can change your email address and request a password reset; those two controls apply only when your account actually has an email-and-password identity.
• Sessions — sign out everywhere in one action.
• Workspaces — the list of workspaces your account belongs to.

Members and invitations

The Members page lists everyone with access to the workspace, alongside a member-capacity summary showing active members against your plan's member limit, with a warning badge as you approach it. At the limit, new invitations are blocked until you free a seat or upgrade.

Owners and admins manage membership; other roles see the list read-only. Managing means:

• Invite — enter an email address and pick a role; a one-line capability hint under the picker tells you what you're granting. The invitation is emailed with an accept link, with a copy-link fallback if email delivery isn't available.
• Pending invitations — re-send an invitation (which issues a fresh link) or revoke it.
• Existing members — change a member's role or disable their membership.

The role model

Every membership carries one of four roles, and they are enforced tiers, not labels:

• Viewer — read-only across the workspace.
• Editor — author policies, curate the catalog, and create and publish deployments.
• Admin — everything editors do, plus data sources, MCP tokens, members, and billing.
• Owner — full control: grant admin or owner, change roles, and manage workspace settings.

Two boundaries are worth calling out: inviting editors and viewers takes an admin, but granting admin or owner — and changing any existing member's role — is owner-only. The full capability table is in create a workspace. Membership changes are all recorded in the activity trail.

Workspace taxonomy

Custom classification types are workspace-level configuration: types you define once — each with a label, category, sensitivity level, PII flag, and description — that then behave exactly like the built-in taxonomy everywhere classification happens. Management lives in the catalog's Taxonomy tab, which is the single home for classification types; the Settings taxonomy address remains as a redirect there so older links keep working.

Defining a custom type ripples through the product: it appears in the per-column classification selectors on every catalog table, it is counted in classification summaries and the catalog's classified-tables stat, and — because canonical policies target catalog vocabulary, taxonomy types included — it becomes something a policy can scope to directly (see policy YAML). Curating taxonomy is editor work rather than admin work: it shapes governance vocabulary, not workspace access.