Skip to content

Platform overview

Blarass PM is multi-tenant. Everything starts from these concepts.

Workspaces

A workspace is a tenant: its own projects, members, and keys. Workspaces are created by the platform operator key (see below), not by member keys.

Members and keys

Every actor — human, AI agent, or app — is a member (type: human | agent | app).

Credentials are API keys with the prefix bpm_:

  • Keys are pure credentials. Zero authority lives on the key — possession proves which member is calling, nothing more.
  • One active key per member. Minting while one is active returns 409. Rotating replaces it in place (old → rotated); revoking leaves the member keyless.
  • Keys are shown once. The raw value is returned only in the mint/rotate response and stored only as a hash. Rotate to get a new one.
  • Members carry a workspace role; keys inherit nothing beyond that.

Roles

Workspace ladder (on the member)

RoleAuthority
ownerFull: manage members, mint/revoke/rotate keys, manage projects, bypass project visibility. One seeded owner seat per workspace; not API-creatable.
adminSame as owner except owner-seat protection: manage members and keys, manage projects, visibility bypass.
memberDefault. Read public projects (viewer semantics), act via project roles.

Project ladder (on the project membership row)

RoleCan
viewerRead the project and its milestones, modules, tasks
commenter+ comment on tasks
editor+ create/edit tasks, milestones, modules; add/remove blockers

Visibility

  • Public projects — every workspace member can read them. A member with no membership row on a public project gets effective viewer.
  • Private projects — only members with a project_members row (plus owner/admin bypass) can see them at all; private projects look like 404 to everyone else.

see_assigned_only

A project-membership row can carry see_assigned_only: true (settable only by admin/owner). That member sees only tasks assigned to them in that project. It composes with the row’s role — writes still require editor/commenter as normal, and being assigned-only grants no extra write access.

Platform operator key

Separate from members entirely: a value stored server-side (PLATFORM_ADMIN_KEY), never a row in members/api_keys. It is the only credential allowed on the tenancy routes (GET/POST /v1/workspaces*). When calling workspace-scoped routes, it supplies X-Workspace-Id and acts as a synthetic owner context (writes are attributed to a fixed platform-ops principal; every console mutation is recorded in audit_log).

Admin routes (/v1/admin/*)

Cross-workspace operator routes (list workspaces, mint/rotate/revoke keys in any workspace) guarded by an admin/owner workspace role — used by the operator console.