Implementation status

This is the one page on the site that lists what is and is not verified. "Verified" means verified with evidence by the owner's bar: the operation has run against the real thing (a real Bookbag SSO, the real CodeBook or MadeBook, a live runner) and the run is recorded in the requirements ledger as evidence. Tests against stand-ins do not meet that bar, however many pass.

As of 25 October 2026, nothing is verified. The requirements ledger (278 requirements across every Bookbag workstream) holds 31 implemented_unverified, 10 in_progress, 2 discovered_existing and 235 not_started, and none in any verified status. The counts below were computed from that file and its workstream status updates. The components are being finished and verified now, so the ledger will move; this page describes the date above.

How to read the table

• What exists in the application is read from the code: routes, tables, services and pages. It is not a claim of correctness.
• Ledger status is the requirement's status in the ledger. not_started does not mean no code exists; it means nobody has recorded the requirement as implemented, let alone verified.
• Pages in the shell lists a page only when its component has marked it ready.

Status by area

Area	What exists in the application	Ledger status	Pages in the shell
Traces	Ingestion over the SDK format, HTTP and OTLP/JSON with receipts; traces, spans, attributes and events; sampling and redaction; saved queries; exports and deletions	EV-002 to EV-009: 8 not_started	Traces, trace detail, Errors, Ingestion, Exports, Settings
Datasets	Datasets, schemas, examples, immutable versions, splits, slices, leakage checks, import and export, curation, synthetic generation, governance	EV-010 to EV-018: 9 implemented_unverified	Datasets, dataset detail, Schema, Examples, Versions, Slices, Leakage, Import, Export, Candidates, Generate, Governance
Scorers	Registry and versions, deterministic scorers, rubrics, LLM judges, pairwise, calibration, runner claims	EV-019 to EV-028: 10 not_started	Scorers, scorer detail, Versions, Rubrics, Calibration, Runners
Evaluations	Routed API for suites and versions, evaluations, experiments, reports and bundles, target bindings, the public /api/v1 evaluation endpoints and the peer endpoints	EV-031 to EV-038, EV-045, EV-048, EV-051, EV-053 to EV-055: 12 not_started, EV-038 implemented_unverified (recorded by the CodeBook workstream), EV-055 in_progress	none: Suites, Experiments and Reports are not ready
Review	Routed API for queues, items, score definitions, online policies, alert rules and events	EV-029, EV-030, EV-039, EV-040: 4 not_started	none: Review, Online scoring and Alerts are not ready
Improvement	An entity list and extension files; no routes, no pages	EV-041 to EV-044, EV-046, EV-047: 6 not_started	none: Failure clusters, Investigations and Proposals are not ready
Impact	Metric dictionary, source events, baselines, impact contracts with revisions, reports, surveys, usage and cost allocation	IMP-001 to IMP-022 and EV-049: 23 not_started	Impact, Metrics, Sources, Contracts, contract detail and revise, Reports, Surveys, Usage & cost
Projects and access	Projects, members and project roles, environments, targets, capture and retention policy, API keys and runner tokens, the free-plan limit, sign-in and sessions	EV-001, EV-052: in_progress; PLT-010, PLT-012: implemented_unverified	Overview, Settings (General, Members, Environments, Targets, API keys, Privacy & retention), organization home
Integrations	Peer links and endpoints, outbox and inbox delivery, the MadeBook decision flow, the capability register page, governance views	CON-020 (the register): not_started; CON-001: discovered_existing; EV-038, CB-026, MB-022, MB-023: implemented_unverified (recorded by the CodeBook and MadeBook workstreams)	Integrations, Capabilities, Governance, governance action detail
Platform	Organization settings, hash-chained audit log, jobs, outbox and inbox administration, readiness	PLT-001, PLT-002, OPS-007, DX-006: implemented_unverified; EV-050: not_started	Admin (Audit log, Jobs & deliveries, Readiness); Organization (Audit log, Deliveries & jobs, Settings)

The capability register

The capability register records every adapter operation with its status (verified_live, verified_standin, implemented_unverified, in_progress, not_built), assurance and evidence. No operation is verified_live. EvalBook has never talked to the real MadeBook or the real CodeBook: the peer link, event, dispatch and decision operations are verified_standin, tested against fakes of the sibling products. Both runner drivers are not_built; no executable scorer has run against a live runner. A release gate may rely only on verified_live operations, so no gate relies on any operation in the register yet. See Capability register and Executable verification.

The sibling sites record the same: nothing has yet crossed to a real EvalBook (https://codebook.work/docs/integrations/linked-products, https://madebook.ai/docs/governance/evalbook-evidence).

What moves a row

A requirement leaves not_started when its workstream records implementation and test references, and becomes verified only when a live run is recorded as evidence. A register operation becomes verified_live when it runs between the deployed products and the run is recorded with the date, each product's commit, the environment and the outcome. Nothing on this site claims verification this page does not show.