The Containment Model

SpecBridge organizes data in a hierarchical model. Organization and Tenant are two different, nested layers — don't confuse them:

• An Organization is your whole company's account on SpecBridge. If you're on SpecBridge Cloud, this is what you signed up for and what your plan/billing is attached to. If you're on a self-hosted (Enterprise) deployment, there is implicitly exactly one organization — your deployment — and you won't see organization-management screens at all.
• A Tenant is a workspace inside your organization — a second, nested layer for splitting up teams, departments, or business units that each want their own spaces, projects, and members while still belonging to the same organization.

Organization (your company's SpecBridge account)
└── Tenant (a workspace inside the organization — team/department)
     ├── Spaces (teams or squads)
     │   ├── Sprints (time-boxed iterations, sprint-mode spaces)
     │   ├── Members (users with a discipline + level)
     │   └── Specs
     ├── Projects (delivery units)
     │   ├── Remote URLs / Git Connection (linked repository)
     │   └── Specs
     ├── Members
     ├── Constitution (spec-writing conventions)
     └── Drafts (captured content, auto-expired)

Organization

Your company's account. On SpecBridge Cloud, every organization gets its own isolated database — nothing about your specs, projects, or members is ever shared with another organization. Organization-level concerns are billing, plan tier, and platform-wide admin (see the Cloud-only docs section). Self-hosted (Enterprise) deployments skip this layer entirely — there's exactly one organization, yours.

Tenant

A workspace inside your organization, with its own isolated users, spaces, projects, and specs. Most organizations start with a single tenant; larger ones use multiple tenants to separate teams or business units that shouldn't see each other's day-to-day work while still sharing one SpecBridge account.

Space

An organizational unit within a tenant. Think of it like a team or squad. Each space has a short code (e.g., CORE) and runs in either sprint mode (time-boxed iterations) or backlog mode (continuous flow). Spaces contain specs, members, and — in sprint mode — sprints. Each space also has its own Kanban board, in addition to the tenant-wide board that shows specs across every space.

Project

A delivery unit that tracks work across specs. Projects can connect to a real Git repository (GitHub, GitLab, or Azure DevOps) — once connected, commits and pull requests referencing a spec automatically link back to it and can advance its status. See the Git Connections & Code Bridge page for detail.

Spec

A specification document. Specs have a type (Epic, Story, Task, or Subtask), a lifecycle status, version history, comments, and stage plans. They can be organized in a parent-child tree structure:

• Epic — a large, cross-cutting feature (top-level, no parent)
• Story — a user story (child of an epic, or standalone)
• Task — a work item (child of a story or epic)
• Subtask — a smaller task (child of a task)