Organization
An organization is the top-level entity in HoneyHive. It represents your company or team and serves as the boundary for billing, SSO configuration, and organization-wide settings.- Users are members of one or more organizations.
- SSO and SAML providers are configured at the organization level.
- Organization admins manage members, workspaces, role definitions, and templates.
- Custom role definitions are configured per-organization via Settings > Organization > Roles (Teams and Enterprise plans).
Workspace
A workspace is a team boundary within your organization. Use workspaces to separate teams, departments, or business units that need independent access controls and configurations. Each workspace has its own:- Members and roles — control who can access the workspace and its projects
- AI provider keys — configure API keys for LLM evaluators and the Playground (see Provider Keys)
- Projects — each workspace contains one or more projects
- Separate access controls (e.g., the ML platform team vs. the product team)
- Different AI provider configurations (e.g., one team uses Azure OpenAI, another uses AWS Bedrock)
- Clear data boundaries between teams
For smaller teams, a single workspace with multiple projects is a common setup. You can always add more workspaces as your organization grows.
Project
A project is the boundary for a single AI application or agent. All observability and evaluation data lives within a project:- Traces and spans — runtime telemetry from your application
- Datasets and datapoints — test data for offline evaluation
- Experiments — evaluation runs comparing model performance
- Metrics and evaluators — quality scoring definitions
- Prompts — managed prompt templates and versions
- Charts and dashboards — monitoring views
Self-Hosted Deployments
The additional scope levels described in this section apply to Dedicated Cloud and Self-Hosted deployments only. Multi-Tenant SaaS customers use the three-level hierarchy described above.
System
The system scope exists for one-time platform bootstrap during initial deployment. It is used only during federation initialization and is not accessible during normal operation.Control Plane
The control plane scope manages organization creation and federation configuration. It handles authentication, RBAC policy, and organizational metadata. The control plane has no access to service-domain data stored in data planes.Data Plane
A data plane is a physical isolation boundary for data and PII. Each data plane is hosted on a dedicated infrastructure cluster, ensuring that application data (traces, evaluations, datasets) from one data plane is isolated from another. Data planes sit between the organization and workspace levels. Within a data plane, workspaces and projects function exactly as described above — the data plane adds a layer of physical infrastructure isolation on top of the logical team isolation that workspaces provide.- Data plane admins can create and manage workspaces within their data plane.
- Data plane admins cannot access organization-level configuration or other data planes.
- Users in one data plane cannot see or query data from another data plane.
When to use workspaces vs. projects
| Scenario | Recommendation |
|---|---|
| One team, multiple AI applications | One workspace, one project per application |
| Multiple teams, each with their own apps | One workspace per team, projects within each |
| Shared platform team serving multiple product teams | One workspace per product team, platform team members added to each |
| Strict data isolation between business units | Separate workspaces per unit |