Skip to main content
Human onboarding is role-based and cohort-specific. A dated platform gate cannot replace current role assignment, scoped access checks, persistence proof, or human approval.

​
Current readiness status

The May 2026 result of 60 completed runs and 3,000 reviewed prompts is a dated platform lifecycle gate. It is not the current release identity, a current database count, human approval, or proof that a role or cohort is ready now.

​
Required before onboarding

Human employees/evaluators should not be onboarded until:
  1. The current product and deployment identity are recorded.
  2. Clerk authentication works for the cohort.
  3. Each participant has the intended Eval Labs application role.
  4. Durable server and data authorization enforce that role and the expected ownership scope.
  5. The user’s visible surfaces match Eval Labs Roles and Access Matrix.
  6. Real runs save durably and reload from the correct scoped view.
  7. Owner/admin can inspect shared persisted evidence through Team Review or Analysis where oversight applies.
  8. Human review process is clearly distinguished from AI-reviewed platform testing.
  9. Behavioral Observatory persistence and access boundaries are verified before assigning saved-label work to employees.
  10. Any active-hardening caveats are named before work begins.
The deployed source defines the product gates, but onboarding readiness must still be verified for each person and cohort. This documentation review did not authenticate as each role or recheck database persistence.

​
Current role boundaries

  • Owner: broad product access, including the owner-only Platform Runtime Registry and its manual verification boundary.
  • Admin: broad product access except the owner-only Platform Runtime Registry.
  • Evaluator: evaluator workbench routes, including verification, controlled batches, owned runs, and saved custom-prompt suites; no owner/admin oversight surfaces such as Team Review or Analysis.
  • Tester: Custom Prompt Test, Auto-generated Prompt Test, owned eligible runs, and saved custom-prompt suites; no verification, controlled batch, Guest verification, Team Review, or Analysis access.
  • Unassigned or unrecognized: fails closed.
Every recognized role can use keyboard-review controls on review routes the role is allowed to open. Keyboard-review availability does not widen route access or permit a role to review another user’s protected evidence. Saved custom-prompt suites are available to owner, admin, evaluator, and tester roles. Evaluators and testers may open source-defined saved-suite deep links such as:
A saved-suite deep link remains subject to the current user’s role and data scope.

​
Cohort gate

Before onboarding a cohort, record fresh evidence for all ten checks above. Do not substitute the May 2026 60-run result for current authentication, route, authorization, persistence, or role-readiness proof.

​
Tester boundary

Tester is the entry-level prompt-testing role. Testers can use:
  • Custom Prompt Test
  • Auto-generated Prompt Test
Testers cannot use Verification Check, Verification Results, Controlled Batch Runner, Guest verification, Team Review, Analysis, the Platform Runtime Registry, Behavioral Observatory, or owner/admin tools.

​
Evaluator boundary

Evaluator is the full evaluator workbench role. Evaluators can use evaluator-safe test surfaces and their own run/review/history routes. Evaluators cannot use Team Review or Analysis. Those are owner/admin oversight surfaces. Evaluators can use their saved custom-prompt suites and the corresponding suite deep links within their own permitted scope. Evaluator workspace polish remains active hardening; do not describe the evaluator UX as fully final while that work continues.

​
Do not overclaim

Do not describe Eval Labs as broadly production-mature or open-access. Do not describe Lucia as human-approved from AI-reviewed gate results. Correct language: