Four independent role dimensions
MSOCK does not have one all-powerful role. Access is assembled from four independent dimensions, and a person can hold values in more than one.
| Dimension | Examples | What it controls |
|---|---|---|
| Administrative scope | Platform administrator, enterprise administrator, workspace administrator | Which organisations, workspaces, users, features, devices, and distributions you can administer |
| Workspace persona | Engineer, Capability Lead, Guild, Product, QA, Security, Release Manager, Leader | Which SOCM review and approval slots you can satisfy |
| SOCK role | Consumer, Creator, Knowledge Custodian | Whether SOCK is read-only or can build, release, and—when enabled—publish knowledge |
| Platform operator role | Platform Admin, Platform Operator, Platform Support | Platform-operations identity; no distinct capability branch between the three labels is exposed by the current application |
Administrative scope
| Role | Scope | Typical responsibilities |
|---|---|---|
| Platform administrator | The platform | Onboard enterprises, manage operators and platform availability, inspect devices, triage bug reports, and administer add-ons |
| Enterprise administrator | One enterprise | Create and manage workspaces, manage enterprise users and settings, set the feature ceiling, and read enterprise usage |
| Workspace administrator | One workspace | Manage members and roles, finish workspace setup, narrow features, and manage workspace distributions |
The Admin Console adapts to the scope in your identity. Seeing the Admin Console chip does not mean every administrative action is available.
SOCK roles
| SOCK role | Read published knowledge | Build a harness | Release locally | Publish to the team |
|---|---|---|---|---|
| Consumer | Yes | No | No | No |
| Creator | Yes | Yes | Yes | When workspace distribution is provisioned and enabled |
| Knowledge Custodian | Yes | Yes | Yes | When workspace distribution is provisioned and enabled |
Creator and Knowledge Custodian currently have the same product capability. Assign them according to your organisation's governance model rather than assuming the names enforce different actions.
Workspace personas
Personas are used by SOCM Command Center to route gate decisions and review work. They do not grant SOCK write access or administrative scope.
| Persona | Typical gate responsibility |
|---|---|
| Product | Product intent and Gate 1 / Gate 4 decisions |
| Guild | Architecture and Gate 1 / Gate 2 decisions |
| Capability Lead | Technical ownership across Gates 1, 2, and 4 |
| Engineer | Implementation and Gate 3 peer review |
| QA | Independent certification evidence |
| Security | Security review when required |
| Release Manager | Release coordination |
| Leader | Portfolio visibility and oversight |
Diagnose an access problem
1. Identify the action that is unavailable, not only the screen. 2. Check whether it depends on administrative scope, workspace persona, SOCK role, or a feature setting. 3. For SOCK build and release actions, confirm the member is Creator or Knowledge Custodian and that workspace setup has completed. 4. For team publishing, also confirm distribution is enabled for the deployment and workspace. 5. For a SOCM approval, confirm the person's persona matches the required reviewer slot.
Do not ask for a broader administrative role when the missing permission belongs to a different dimension.