Skip to main content
Eval Labs authorization has more than one layer: Clerk authenticates the participant and supplies an application role, the client filters routes and actions, ownership scopes evaluator/tester work, and durable server/data authorization protects evidence.

​
Authentication and role assignment

The recognized application roles are owner, admin, evaluator, and tester. Missing or unknown roles fail closed for protected routes. Read the compact surface matrix: Eval Labs Roles and Access Matrix.

​
Owner

Status: implemented. Owner can use every declared Eval Labs product surface, including:
  • testing launchers and Eval History
  • running and Review Queue routes
  • Keyboard Review Mode
  • guest verification and controlled batches
  • Team Review, Analysis, Human Eval Research, and single-eval analysis/diagnostics
  • Registry Diagnostics and Behavioral Observatory
  • the Platform Runtime Registry
Platform Runtime Registry is owner-only. This is the current material difference between owner and admin surface access.

​
Admin

Status: implemented. Admin has privileged testing, shared evidence, oversight, and Analysis access. Admin can use Registry Diagnostics, Behavioral Observatory, and the Fieldwork Communication Baseline launcher. Admin cannot use the Platform Runtime Registry under the current source gate.

​
Evaluator

Status: implemented; polish and rollout hardening remain active. Evaluator can:
  • use Custom and Auto-generated Prompt Tests
  • save, load, delete, and deep-link saved custom suites
  • use guest verification and the Controlled Batch Runner
  • use Eval History for own scoped work
  • open own running and Review Queue routes
  • use Keyboard Review Mode on an allowed Review Queue route
Evaluator cannot use owner/admin oversight, Analysis, Registry Diagnostics, Behavioral Observatory, Human Eval Research, Fieldwork baseline launch, or Platform Runtime Registry surfaces.

​
Tester

Status: implemented as the narrower human-evaluation lane. Tester can:
  • use Custom and Auto-generated Prompt Tests
  • save, load, delete, and deep-link saved custom suites
  • use Eval History for own allowed work
  • open own allowed running and Review Queue routes
  • use Keyboard Review Mode on an allowed Review Queue route
Tester cannot use guest verification, Controlled Batch Runner, Fieldwork baseline launch, oversight, Analysis, Registry Diagnostics, Behavioral Observatory, Human Eval Research, or Platform Runtime Registry surfaces.

​
Keyboard Review Mode

/keyboard-review-mode is a shortcut reference available to every recognized role. The shortcuts act only inside an already-authorized Review Queue. They do not create a separate review permission or bypass ownership checks.

​
Saved custom suites

All four recognized roles can save custom prompt suites and open /lucia/custom/suites/:suiteId. Suite access does not imply access to another user’s persisted runs, reviews, or evidence.

​
Durable authorization

Frontend route checks and durable server/data authorization must agree. Authorization enforces privileged access and evaluator/tester ownership scope independently of what the browser renders. Use this evidence rule:
Platform Runtime Registry evidence has a separate owner-only authorization boundary. Fieldwork evaluations use specialized durable evidence contracts rather than the ordinary Eval Labs run/review lifecycle.

​
Current labels and maturity

The current analytics label is Analysis. /analysis is canonical; /experiments is a legacy alias. Use these maturity terms:
Do not describe UI visibility, local browser state, or a historical readiness gate as current production evidence.