Roles and permissions
What each of the four perspectives can do, where those rights come from, why switching perspective never widens them, and the distinction between management target and current workspace.
One deployment, one Organization
A deployment has exactly one Organization. There is no multi-organisation creation, switching or archiving semantic.
A member is a human account with a stable identity inside that single Organization. A member cannot join or switch to another one.
There are three Organization-level roles: administrator, operations and member. Administrator and operations hold exactly the same platform operations capabilities; the administrator governs organisation team members, platform roles and workspace assignments on top of them, and nothing else.
Workspace
A Workspace is the logical collaboration scope inside the Organization that carries membership authorisation and shared capabilities. It is not bound to a code repository, and may contain several.
There are three Workspace roles: administrator, member and viewer.
Platform administration does not confer workspace data rights by itself. An operations role that has not joined a given Workspace cannot see the tasks, knowledge or artefacts inside it.
The four perspectives
The four perspectives in the interface must come from real persisted authorisation, not from demo parameters.
Member is the day-to-day perspective of anyone who is a member of an authorised Workspace. It reaches conversations, development environments, tasks, automation, knowledge, memory, the marketplace and personal connectors.
Workspace administrator derives from membership of the current Workspace and governs that Workspace alone. On top of member capabilities it adds team overview, member management, member usage, cost analysis and model quota.
Operations is a formal platform role within the single Organization, holding every platform operations capability. On top of member capabilities it adds the resource dashboard, provider clusters and sandboxes, workspace lifecycle, sandbox policy, enterprise instant messaging, the model gateway, Git services, knowledge and marketplace management, and connector exposure policy.
Administrator holds exactly the same platform operations capabilities as operations, and governs team members, platform roles and workspace assignments on top of them.
Switching perspective regroups navigation; it does not widen permission. Every read and write is still authorised by the control plane against the signed-in principal, the Organization and Workspace membership. A non-administrator who constructs a deep link must receive an authorisation denial — hiding the navigation entry is not the control.
Account boundaries for a member
Disabling an account preserves memberships and is reversible.
Deleting an account revokes every membership and all sign-in access, and retains a permanent tombstone carrying the deletion time and the operator, together with historical business references. It cannot be restored by re-enabling. The old email address is kept on record so that automatic provisioning cannot resurrect the account.
Removing someone from a Workspace revokes only that Workspace membership and leaves the platform account untouched.
To create a member account, an administrator supplies the sign-in email, the display name and the target Workspace role; the server creates a sign-in-capable human account and joins it to the target Workspace immediately. The server generates the initial password at random, and the user, the organisation membership and the Workspace membership are written in one transaction.
An email address that already exists is always refused rather than re-provisioned. An existing password is never overwritten, and existing account authorisation is never modified implicitly.
The initial password is held in the memory of the current drawer only. It does not enter a cache, browser persistent storage or a log, and it is cleared when the drawer closes or the management target changes.
Authentication modes
A local account signs in with a unique email address. An enterprise identity is linked to a member inside the Organization through an identity binding.
An active binding is unique on both sides — on the member and on the external identity. Switching provider retains the inactive history and requires an explicit rebind. External identities are not merged automatically by email address, because automatic merging would let a change in who owns an email address silently change permissions.
Management target and current workspace
Configuration pages inside the workspace catalogue must distinguish explicitly between the current session Workspace and the management target Workspace.
Entering member, model key, sandbox or provider management from the workspace list changes the management target only; it does not switch the current Workspace of the product shell.
The distinction is easy to overlook, and the consequence is concrete: if the two are conflated, an administrator configuring Workspace B can switch their own context to B without noticing.