Vocabulary
Orunbase's tenancy model is a four-level hierarchy: Account → Workspace → Project → Environment. This page defines each term, the actors that operate on them, and the identifier formats you'll see in IDs, tokens, and API responses.
Account
An Account is the tenant: the top-level unit that owns billing, the GitHub connection, and the usage roll-up. Internally it is a parent organization — a standalone workspace is its own account, and a workspace with children resolves billing and integrations up to its parent.
Account-scoped roles — account_owner, account_admin, account_billing_admin — are granted on the account and cascade to authority on every workspace under it, without per-workspace grants. See RBAC.
Whether an org is an account root is relational state, not something encoded in its id: the invariant is accountId === workspaceId exactly when the workspace is the account root. Never branch logic on a parsed id prefix — authority comes from the resolved record.
Workspace
A Workspace is where day-to-day work lives: projects, environments, members, audit. It is the unit you select in the console (app.orunbase.com/{account}/{workspace}/…), pass to the CLI, and commit into intent.yaml.
The API's canonical name for a workspace is organization — a workspace is an organization row; there is no separate entity. Canonical paths read /v1/organizations/{orgId}, and /v1/workspaces/* is an accepted alias that rewrites to the same handlers. On the alias surface, responses carry a workspaceId field alongside every orgId (same opaque org_… value), and request bodies accept either spelling. The legacy surface — /v1/organizations/*, the orgId field, --org — keeps working indefinitely; the Workspace vocabulary is purely additive.
A workspace has three identifiers. Do not conflate them:
| Identifier | Role | Mutable? | Where it appears |
|---|---|---|---|
Workspace ID ws_… | Durable public handle | No | API paths and bodies, SDK/CLI, console "copy ID", intent.yaml |
| Slug | Vanity / URL label | Yes | Console URLs (/{account}/{workspace}/…) |
org_<hex> | Internal primary key and legacy public id | No | API responses (orgId), /v1/organizations/* paths, audit events |
The Workspace ID is ws_ plus a Crockford base32 body (e.g. ws_3KF9TQ2P), generated once at creation and never changed — safe to commit and quote forever. The slug is friendly but mutable, so it is unsafe as a stored reference. Where the API takes a workspace reference in a path, the edge resolves all three forms — ws_…, slug, or org_<hex>.
Project
A Project is the operational boundary where product work happens — in the current vocabulary a project maps one-to-one to a repo. Projects hold environments, configuration, remote state, runs, and git links. Id prefix prj_. See Projects and environments.
Environment
An Environment is an optional deployment/configuration boundary inside a project (for example stage and prod). Id prefix env_.
Agent kind
An agent kind classifies what an agent is for on the console's Agents surface: a chat you steer, a task agent working a task on a branch, a design agent turning an epic into a design and proposed contracts, or a standing routine that fires on a trigger. A session's kind is resolved from its profile's agent type (implementer → task, orchestrator → design).
The name Implementer is retired — those agents are Task agents now. The command palette still answers the old name as a synonym, but new docs and UI say task agent.
Baseline
A baseline is a complete, production-shaped product repository that Orunbase rebuilds under your name — your GitHub organization, your cloud account, your product name — from the baseline registry. A registry row carries identity and commerce (id, visibility, tier, source repository, pinned tag, expected build time, required providers); the build contract lives in the baseline's own blueprint card. Orunbase maintains the public rows; a Business-plan account may register its own. See Baselines.
What is Orunbase? also calls orun-cloud itself an "open, forkable baseline" — a repository you fork by hand. A registry baseline is a build the platform runs for you.
Blueprint card
A blueprint card (blueprint.yaml) is the build contract of a baseline, fetched from its source repository at the registry's pinned tag: the inputs the console asks for and their validation patterns, the provider integrations required, a preview of the secrets the build mints, the programme (one epic and a milestone per phase), the build document the engine runs, and the URLs a finished build must answer. Everything the console shows about a baseline comes from its card.
Repository link
A repository link (repl_…) binds a project to one repository on the GitHub App connection, with the agent's write posture. It is created from the repository's Git tab or by the baseline flow's Repository step, and it is what a baseline build and a grounded agent session need. It is distinct from the workspace link that orun cloud link creates, which maps a git remote to a (workspace, project) pair and allow-lists the repo for CI. See State plane.
Build session
A build session is the agent session (as_…) that builds a baseline: a sandbox the platform provisions with a time-boxed admin grant on the workspace, running the baseline's blueprint through orun. One runs per repository at a time; it is watched from the Overview's build panel and from its own session page under Agents. See Build from the console.
Actors
Every API request acts as one of four actor kinds; audit events record which:
| Actor kind | What it is | Authenticates with |
|---|---|---|
user | A human, signed in via the console | Session token (sps_ses_<id>.<secret>) |
service_principal | A machine identity created as a workspace API key | The API key secret as a Bearer token |
workflow | A CI run (GitHub Actions) | OIDC exchange (POST /v1/auth/oidc/exchange), minting a token bound to (workspace, project) |
system | The platform itself (internal jobs) | Internal only |
See Authentication and CLI and CI auth.
Identifier prefixes
Public ids are prefixed so you can tell what kind of thing an id refers to at a glance:
| Prefix | Kind |
|---|---|
ws_ | Workspace ID (durable public handle; Crockford base32) |
org_ | Organization / workspace (legacy public id; 32-hex body) |
prj_ | Project |
env_ | Environment |
usr_ | User |
team_ | Team |
mem_ | Workspace member |
inv_ | Invitation |
ses_ | Session |
as_ | Agent session, including a baseline build session |
int_ | Integration connection |
repl_ | Repository link |
sps_ses_ | Session token (sps_ses_<id>.<secret> — id plus secret, not a bare id) |
chl_ | Sign-in challenge (email-code login) |
req_ | Request id (meta.requestId and the x-request-id header) |
Prefixes are a readability convention, not an authorization mechanism — servers resolve the record behind the id before trusting anything about it.