Projects
A project is EvalBook's work container. Creating one, its settings, archiving it with its exact name, the free-plan limit, and how it links to CodeBook and MadeBook workspaces.
A project is the container everything else lives in: traces, datasets, scorers, suites, reports, review queues, proposals, impact contracts, API keys and peer links. One Bookbag organization owns many projects; a project belongs to exactly one organization. There is no shared workspace table across the Bookbag products: CodeBook has workspaces, MadeBook has workspaces, EvalBook has projects, and a peer link records that two of them are the same work.
Status (25 October 2026). Projects, members, environments, targets, capture policy, retention and the project overview are in the application (requirement EV-001 is in progress in the requirements ledger and being verified now). Nothing on this page is marked verified.
Creating a project
Projects → New project asks for a name and a slug. The slug is unique within the organization; the name may contain anything. The person who creates the project becomes its first project_admin. There is no demo data: a new project is empty until something sends it a trace or somebody creates a dataset.
Organization owners and admins can create projects. So can any member of the organization, subject to the plan limit below.
The overview
A project's Overview is the first page of the project: what has arrived recently, what is running, and what needs a person. Every figure on it carries its source, and a figure that cannot be computed is "—", never 0. A project that nothing has been sent to says so.
Settings
Settings has six pages. Who may open each is decided on the server from your project roles.
| Page | What it holds | Needs |
|---|---|---|
| General | Name, slug, archive | project.read to see, project.admin to change |
| Members | Members and their project roles; organization owners and admins are listed separately because they need no row | member.manage to change |
| Environments | Named environments a span, target or API key can be bound to | project.admin to change |
| Targets | What is evaluated: an application, a model configuration, a repository; see Environments and targets | project.admin to change |
| API keys | Project API keys (evb_…), shown once; see API keys |
apikey.manage |
| Privacy & retention | Capture policy, redaction rules, retention per content class, retention receipts; see Redaction and capture | settings.privacy to change |
Every write carries the row's revision; a stale edit is refused with 409 VERSION_CONFLICT and the page reloads the current values. Every write is audited in the same transaction.
Members
A member must be an active member of the organization at SSO; a pending SSO invitation cannot be added to a project. A member holds one or more project roles, and holds the union of what they allow. A project never loses its last project_admin: removing them or their role is refused with LAST_PROJECT_ADMIN.
Archiving and restoring
Archiving is the project's only lifecycle change:
active ──archive (type the exact name; checked on the server)──▶ archived
archived ──restore (plan limit re-checked)──────────────────────▶ active
An archived project is readable and restorable and refuses every other write (PROJECT_ARCHIVED). Nothing is deleted by archiving. The archive dialog asks for the project's exact name and the server checks it; the dialog alone is never the protection.
The plan limit
EvalBook is free at launch and reads your organization's plan from Bookbag SSO only to show it. The one limit it enforces itself is three active projects per organization on the free plan. Creating or restoring a fourth is refused with:
{ "data": false, "code": "PLAN_LIMIT",
"error": "The free plan includes 3 active projects; this organization has 3. Archive one, or change the plan at Bookbag SSO.",
"gate": { "feature": "projects", "plan": "free", "limit": 3, "used": 3, "manage_url": "…" } }
When SSO cannot say what the plan is and nothing is cached, the limit is not applied (SSO's rule for every product). A plan change never deletes evidence, never converts a deny into an allow, and leaves historical reports readable and exportable.
Links to CodeBook and MadeBook
A project can be linked to one CodeBook workspace and one MadeBook workspace. Links are made and ended under Integrations, by a project admin, and are stored on both sides. A link is what authorizes everything that crosses between the products: evaluations requested by a CodeBook station, spans exported from its runs, reports MadeBook asks for, decisions EvalBook asks MadeBook to make. See Peer links.
A MadeBook link cannot be ended from EvalBook without MadeBook's allow on an unlink_governance decision; the page says so and points to MadeBook, whose own unlink ends the link here.