Organization and project
Every request you make to the platform is answered in the context of one organization and one project. Knowing which is which explains most of what you can and cannot see.
Organization
An organization is the tenant: one company, or one team that bills and administers itself. It owns the user accounts, the roles those users hold, the device fleet, and every project underneath it.
Your account belongs to at least one organization, and an account with no organization is refused before any other check runs. During the current alpha a platform administrator creates the organization and the account, and the sign-in page routes an unknown email address to support rather than to a sign-up form.
Within an organization a member holds one of three roles.
| Role | What it carries |
|---|---|
owner | The organization's ultimate administrator. |
admin | Administers members and organization settings. |
member | Ordinary access to the organization's work. |
These sit alongside the platform's permission system, which grants capabilities such as devices:write or benchmarks:read through roles bound to your account. What you can do is the intersection: the capability must be granted, and the resource must be inside an organization and project you belong to.
Project
A project is the box one piece of work lives in: its models, benchmark runs, jobs, services, artifacts and runtime credentials. Every organization starts with a default project, and the project switcher in the top bar decides which one you are looking at. Nothing you create lands outside a project.
Project membership is separate from organization membership, and it is enforced: a member of the organization who is not a member of the project cannot read the project's resources. A project member holds one of four roles.
| Role | What it carries |
|---|---|
owner | Full control, including deleting the project. The last owner cannot be removed or demoted. |
admin | Manages members and resources. |
developer | Creates and runs the project's work. |
viewer | Reads it. |
Devices are the exception
Devices belong to the organization, not to a project. Every project of an organization sees the same fleet, and a device registered once is available to all of them. This is deliberate: a physical device is a piece of shared hardware, and forcing it into one project would mean re-registering it for the next.
Everything else is project-scoped. A resource in another project answers 404, exactly as a resource in another organization does, so you cannot learn what exists elsewhere by probing ids.
Where you see it
- Web UI
- CLI
- Claude
The organization switcher sits top left, the project switcher top right. Settings, then Organization, holds the organization's members and its identity-provider settings. A project's own members are on its dashboard, under Members.
clika-rt login --profile <name> # saves the deployment URL and your credential
clika-rt projects list
clika-rt orgs list
A profile carries one deployment and one credential, so switching deployments is a --profile flag rather than a re-login.
Ask Claude:
Which projects can I see, and who are the members of the one I am in?
That reaches the get_projects and get_projects_id_members tools. See Set up MCP for Claude.
Related pages
- Device, the org-scoped exception.
- Runtime licenses, for the runtime credentials a project issues.
- Manage members and API keys, for the day-to-day operations.