Workspaces, projects, and target systems
Definition
Workspaces, projects, and target systems define where organizational access, product-specific correctness work, and the AI behavior under evaluation are separated. A workspace groups people and administration; a project holds the cases, standards, coverage, and benchmark evidence for a specific target behavior.
Use this reference when a reader needs to know whether an artifact belongs to an organization boundary, a project boundary, or the target system being evaluated.
Fields, states, or lifecycle rules
- Workspace boundaries should not be used to infer project-level correctness decisions.
- Project boundaries keep cases, policies, rubrics, coverage, benchmark versions, and review context tied to a specific target behavior.
- Target-system identity matters for benchmark-level run metadata and comparison interpretation.
- Cross-project reuse should not imply cross-project approval.
- This page does not make billing, tenancy, deployment, or compliance claims.
Related objects
Workspaces, projects, and target systems should be read with Product map, Product boundaries, Permissions, and Run metadata.
Worked example
Workspaces, projects, and target systems boundary
Start
Behavior input
- Scenario
- The same company evaluates a support assistant and an internal policy-search assistant.
Middle
Judgment into standard
- Project boundary
- Each assistant has its own cases, policies, rubrics, benchmark versions, and benchmark-level run metadata.
Result
Interpretation
- Interpretation
- A passing benchmark in the support project should not imply the policy-search assistant has approved evidence.
Source confidence
Code-backed: Project and workspace types establish organization and Project identity; member settings expose Project participation; benchmark Run presentation identifies the evaluated target boundary. These sources do not establish billing, deployment, or tenancy guarantees.