# Workspaces, access and roles

A workspace is an organization-scoped environment for saved project evidence, research, decisions and eligible vault records. Authentication identifies the user; membership and server-side permissions determine access to a particular organization.

## Join or create a workspace

Public project analysis at `/app/analyze` can be used before joining a workspace. To save a project or read private records, sign in at `/login` using the available email magic-link flow. Demo entry exists only where the environment permits it.

An authenticated user without active membership receives **Workspace setup**. There are two connected paths:

1. **Accept invitation:** Use the single-use token issued by an existing owner, review the intended role with that owner and submit the required acceptance reason. The server checks the authenticated email, token expiry and organization binding.
2. **Create invited workspace:** Use a qualification-bound provision token issued to your authenticated email. Supply the organization name, canonical slug, exact terms version, HTTPS terms source and creation reason, then record your agreement. Accepted creation records the organization and its first accountable owner together.

Workspace creation is provisioned rather than open self-signup. Submitting **Request access** records an access-interest receipt where connected; it does not create membership, buy a plan or qualify a vault.

Some actions require recent authentication. Complete reauthentication, return to the original page, review the action and submit deliberately. Signing in does not automatically save a project or repeat the sensitive action.

## Select the correct organization

If you belong to more than one workspace, select the intended organization before reading or changing records. Confirm the displayed organization when saving a project, creating a draft or reviewing a command receipt. Changing organization clears or reloads scoped page state; the previous organization's records must not be reused as the new context.

Open `/app/organization` to inspect canonical identity and governing terms: name, slug, ID, creator, creation time, terms version/source, acceptance time and hash. Copy the exact recorded identifiers when asking for help or configuring an integration.

The connected organization screen is primarily an evidence view. Missing identity or terms records remain unavailable. Demo logo, brand and profile controls do not establish persisted organization updates.

## Choose roles by responsibility

The current application defines eight workspace roles:

| Role | Main responsibilities |
| --- | --- |
| Organization Owner | Membership, organization governance, commercial terms, reporting and broad permitted issuer controls. |
| Treasury Admin | Vault creation/funding/exit workflows, studies, drafts and permitted issuer-Safe submission registration. |
| Approver | Independent policy and proposal review without treasury operating rights. |
| Analyst | Studies, strategy/policy/proposal drafts, reports and evidence-grounded explanations. |
| Viewer | Read permitted organization, vault and explanatory evidence. |
| Klineo Operator | Eligibility, preparation, monitoring, reconciliation and internal operations within assigned permissions. |
| Risk Guardian | Pause, bounded risk reduction and incident response. |
| Internal Auditor | Read permitted organizational, vault, commercial, operational and audit evidence. |

These are application responsibilities, not wallet permissions. The API independently authorizes each command, and some workflows require an independent reviewer or exact issuer authority even when a role includes the general permission. The operator role cannot replace issuer approval or withdraw issuer funds. The guardian path cannot expand risk or authorize a treasury sale.

For example, an analyst can prepare evidence but cannot approve policy or execute it. An approver can review a proposal but does not acquire treasury custody. A workspace owner still needs the required external Safe process and current evidence for a financial operation.

## Manage membership

Open `/app/members` to inspect member status, role, effective time, expiry, invitations and immutable role history. An authorized owner can issue an email-bound invitation with role, expiry and reason, change permitted role/expiry fields or revoke membership.

The invitation token is returned once; the server retains its hash. Record it through your approved invitation-sharing process when it is displayed. The app protects the last active organization owner from removal. Demo member controls do not send invitations or grant access.

Use a role that matches the person's job and review expiring access before it interrupts required approvals. If access is rejected, reload the selected workspace and confirm membership; refreshing a page cannot restore revoked authority.

## Product access and operating authority

**Unlock full workspace** opens a configured plan preview while preserving project context. Checkout is not connected in the current implementation. Listed prices, usage illustrations and allowances are not evidence of a purchase or current entitlement.

Workspace subscription access and [vault service fees](/guides/vaults) are distinct commercial workflows. Neither grants issuer identity, private treasury permission, custody or signing authority. Follow [saved project analysis](/guides/projects) for public evidence and the separately verified onboarding path for vault operations.