The capability register
Every adapter operation EvalBook has or will have, with a status, the documentation it was built against, the version tested and its evidence. A named integration is a requirement, not a claim of support.
The capability register is the one list of every operation EvalBook performs against another system: the CodeBook and MadeBook peer calls, Bookbag SSO's model, file and email APIs, OpenTelemetry ingestion, webhook sources, the runner drivers, and every source-control, work-tracking, CI, monitoring and tool integration the specification names. Each row carries a status, an assurance class, the documentation it was built against, the version it was tested with, and its evidence. A named integration is a requirement, not a claim of support. The Integrations → Capabilities page in the app shows exactly these rows and these words.
The register has two copies that a unit test keeps identical: the human-readable document in the application repository and the machine-readable list the page reads (register version 2026-10-15.1). The test also fails when a status claims verification without evidence, or when an entry claims high assurance without a live run.
Statuses
| Status | Meaning |
|---|---|
verified_live |
Ran against the real service; the evidence names the run. No operation has this status today. |
verified_standin |
Automated tests pass against a stand-in: a fake peer that answers as the real product's code does, or the fake SSO. Never run against the real thing. |
implemented_unverified |
Built, but no automated test of the operation exists. |
in_progress |
Another component is building it; the register has not verified it. |
not_built |
Nothing exists. The app shows "Not built" and offers nothing for a gate. |
Assurance
Each operation has an assurance class today and a planned one:
| Class | Meaning |
|---|---|
platform_enforced |
A Bookbag product enforces it and EvalBook checks the result. |
vendor_enforced |
An external system enforces it. |
observation_only |
EvalBook only observes what it is told. |
unsupported |
Nothing to rely on. Every operation that is not built. |
A release gate may rely only on verified_live operations. Since none exist, no gate relies on any operation in this register yet. The gates themselves are being finished; see Release gates.
The register today
As recorded on 15 October 2026, with evidence from the application's unit and end-to-end tests on Node 24, SQLite and the fake SSO. EvalBook has never talked to the real MadeBook or the real CodeBook; the sibling halves were in turn tested against an EvalBook stand-in (see CodeBook as a peer and MadeBook as a peer).
Peers
| Operation | Owner | Status |
|---|---|---|
| Link and unlink a CodeBook workspace | integrations | verified_standin |
| Events to CodeBook through the outbox, each carrying its link | integrations | verified_standin |
| Send an improvement proposal to CodeBook | integrations | verified_standin |
Receive improvement.updated |
improvement | in_progress |
| Serve evaluation requests, status, report, cancel | evaluations | in_progress |
| Serve a project's suites for station settings | evaluations | in_progress |
| Accept CodeBook run and step spans | traces | in_progress |
| Link a MadeBook workspace; MadeBook ending it ends it here | integrations | verified_standin |
| Ask MadeBook for a governance decision | integrations | verified_standin |
| Re-read a decision | integrations | verified_standin |
Receive evalbook_decision.resolved (only the decision id is acted on) |
integrations | verified_standin |
End a MadeBook link only on an unlink_governance allow |
integrations | verified_standin |
| Serve reports for a pull request | evaluations | in_progress |
Bookbag SSO and notifications
| Operation | Status |
|---|---|
| Model completion through SSO, charge deduplicated by idempotency key | verified_standin |
| Large bodies in the organization's file store | implemented_unverified |
| Repository content through SSO repository connections (read profile) | not_built |
| Email through SSO | implemented_unverified |
| Slack and Microsoft Teams notifications | not_built |
Telemetry and runners
| Operation | Owner | Status |
|---|---|---|
| OTLP/HTTP trace ingestion with GenAI semantic conventions 1.37.0 | traces | in_progress |
| Signed generic webhook source for impact events | impact | in_progress |
| Runner container driver (Podman or Docker, no network, read-only root, limits) | scorers | not_built |
| Runner process driver (development only) | scorers | not_built |
Source control, work tracking, CI, monitoring, tools
GitHub (repositories, pull requests, checks, deployments, webhooks), GitLab, Azure DevOps, Gitea; Jira and Linear; GitHub Actions, GitLab CI, Azure Pipelines, CircleCI, Buildkite; Sentry, Datadog, PagerDuty, Grafana and Alertmanager; scoped MCP tools. Every one is not_built, with its vendor documentation not yet consulted. They are listed because the specification names them, and so that the app can say "Not built" rather than nothing.
Moving an operation up
verified_standin→verified_live: run the operation between the deployed products, or their feature worktrees on one Bookbag SSO, and record the run in the register: date, each product's commit, environment, the command or journey, the outcome. Only then may an operation back a high-assurance gate.not_built→ anything: build the adapter against the vendor's current documentation (recorded with its date), test it in the vendor's sandbox, and register it operation by operation. Vendor sandbox credentials are the owner's to supply.
Both copies of the register change together, or the test fails.