Implementation status and current limits
What the current code supports, what is partial, what is not built, and which responsibilities belong to SSO.
Updated 14 October 2026 for the platform AI Models page: every feature that asks a model, its usage, and a per-feature model assignment. The 11 October update covered factory benchmarks, repository-scoped memory, factory and station model policies in the factory definition, and prepared model inputs for native and crew runs. The 8 October update covered reviewed gate and policy packs, approved memory revisions, and evaluator and supervisor input history. The earlier integration audit remains part of this page, with its limits retained. Shipped code, a deterministic local walkthrough and a real-provider production result are different kinds of evidence; none should be substituted for another.
Implemented areas
The code includes factory blueprints (fourteen built in) and update previews, workspace blueprint copies, versions and rollback, scripted simulation, reviewed and scheduled changes, environment chains and promotion with no bypass for policy, rollback, optimizer, blueprint and station-switch changes, crew workers, explicit cross-factory intakes, typed artifacts and contracts, independent evaluators, work orders with partial replanning, workflow, specialist and factory supervisors, dynamic worker routing, model policies with fallback chains and measured choice, outcome records, optimization recommendations, operational controls, scoped memory including shared crew notes and primary-repository notes, factory and station model policies carried in the factory definition, per-call context and token usage reporting, cited knowledge retrieval from uploads, repository files and conversations on GitHub, GitLab and Gitea, pull-request reviews, approved web pages and four ticket/discussion systems, a static code graph for seven languages, repositories on GitHub, GitLab or a self-hosted Gitea, external runtimes including six dedicated vendor adapters, credential leases, egress policy and scanning, the organization concierge, linked MadeBook and OpenBook workspaces with the governance handoff and epics, managed service grants, TypeScript/Python worker SDKs and events.
The documentation explains these bounded capabilities. It does not imply that every broader roadmap feature in the same area is complete.
The System Map and what builds on it — the context pack and its measurement, impact analysis and risk routing, Ask your system, work snapshots, production monitoring and generated docs — are released. Their row below says what that code does not do yet.
Status by area
| Area | Live | Partial or not built |
|---|---|---|
| AI Models | AI Models: every feature that asks a model, generated from the code's feature registry (23 features in four groups), its calls, tokens and model share over 30 days, and a per-feature assignment that steers the call when the organization runs that model | Assignments do not override a factory or station model policy or a worker's pinned model; a self-hosted organization that does not run the assigned model runs its own default, and the page records what really ran |
| Manager settings and models | Board Manager settings opens the installed agent’s fixed/fallback/automatic model policy, permissions, instruction editor and Studio. Chat, every supervisor tier, planning, evaluators and crew participants honor their applicable model policies. Studio instruction releases reach conversations, supervisors and planning invocations, with separate execution counts and readable-role coverage | Role-specific synthetic datasets and human review aggregates are available, with frozen role guidance and separate disagreement counts. Real-provider calibration remains open; planning now pins a released version per invocation and shows work-order history; planner-specific quality calibration remains open |
| Scorers and observer | Real-diff requirements, evidence profiles, workflow/station/agent/file targeting, not-scored reasons, coverage, human feedback and disagreement exclusion. Accepted instruction candidates can be tested before release; improvement yield compares matching evaluations | Real-diff judgment agreement needs representative PRs and human labels. Observer targets remain instruction or factory suggestions; accepting a factory suggestion does not apply it |
| Factory benchmarks | Benchmarks: task sets frozen from the factory's finished runs (workflow, station, feature type, category, label, changed-path and date filters), replays across up to six models and agent versions with the original runs as a judged baseline, grading by the factory's own scorers with one judge per benchmark, cost per task from SSO prices with unknown costs never shown as free, a cost-against-quality frontier chart, and routing proposals that become reviewed changes | Replays are text-only: the model writes its answer without the repository, so diff-reading scorers record not scored. Full repository replays need the runner. Judge cost is not included in a configuration's cost. |
| Studio replay | Historical run cases, a version/model evaluation matrix, original measurements, stale-revision markers and usage/cost comparisons | Frozen fixtures do not reproduce a historical production environment. A Best badge can include stale results; compare revisions. Real-provider outcome calibration remains necessary |
| Factory setup and Trust | Ten-step setup checklist from saved state; ten Trust measures, sample sizes, prior-window comparisons and targets saved by a person | Setup checks do not make a paid model probe. Targets do not change policy. Missing evidence and small samples are not proof of reliability |
| Factory files | Export supported settings and agent instructions as a zip; preview updates or create a factory from the file, including agents and scorers. Required-review targets send supported definition edits through second-person approval and publication. Unsupported side changes are refused before application. Gate counting and wording survive new versions, imports, reviewed edits and rollback; old unrecorded settings are marked unknown. Gate/policy pack installation and removal use second-person review with transactional receipts. Evidence-bound memory is omitted from portable definitions with an explicit count. Factory and station model policies are part of the definition (JSON format 3, ZIP codebook.factory 3): versioned, compared, merged, exported, reviewed and rolled back. A model the receiving organization lacks is left unset and reported as missing, never substituted |
Not a complete environment backup: a worker's own model policy, skill and instruction releases, knowledge revisions, tool grants and runtime bindings are not versioned with the factory. Files in formats 1 and 2 carry unknown model-policy coverage and are never restored as exact. Agent instructions and operational side settings are not covered by factory rollback or definition review; reviewed workspaces protect shared agents from file-based changes through neighboring factories |
| Canary verification | Durable per-run settings and start, stop, comparison and promotion controls. A local authenticated walkthrough verified independent approval, candidate outcomes, comparison data and stopping a canary with a scripted model | Production promotion, every visual panel and quality against real providers/runtimes remain unverified |
| Agent chat files | Uploads, parsing, private reads, source-row deduplication, ticket tools and file exports. A real local SSO/MinIO walkthrough uploaded a CSV, read it through chat and created a ticket | Real HTTP checks cover upload/download/delete, private-session and factory-permission isolation, storage retry and oversized-request refusal. Real-model import quality and all visual paths still need validation |
| Worker SDKs | TypeScript/JavaScript and Python lifecycle clients. The TypeScript ten-step check passed over local HTTP/MCP and correctly ended at human review | A production check is still required; fixture lifecycle completion is not accepted code delivery. Packages are source-installable, not registry releases; .NET and Java remain planned |
| Peer lifecycle | Linked products: links, governed runs under MadeBook, stories in from OpenBook, signed and idempotent reports out with a retryable outbox, and peers, addresses and the secret read from SSO's app registry. The governance handoff: a model check before every attempt, sessions ended on every path, contract and evaluator results as reported evidence, nine audit events, retention of run bodies, acting_for, supervisors as sessions of their own. Epics become work orders whose planned stories wait for approval, sent and approved from OpenBook's Epics page. Steps 0–1 (story to card, governed run with a decision) ran for real between the three products on one SSO |
Steps 2–3 (MadeBook's compliance verdict on a real pull request, and that verdict reaching the story) have never run for real, nor has a governed run covering the handoff; only stand-ins. Stations worked by outside runtimes, crews or another factory are not registered as MadeBook sessions. MadeBook now treats DECISION_REQUIRED as a whole-job stop. Active links have database-enforced workspace/product uniqueness, including concurrent requests. Peer credentials must match the current active link and workspace; concurrent rotation has one winner, and unlink removes access even when token cleanup needs a retry. CodeBook publishes an authorized peer factory list; connected production evidence still needs verification |
| Knowledge and context | Scoped sources and grants, lexical/semantic retrieval, embeddings, source revisions, reviewed domain extraction, immutable native/external/crew participant context records with revisions, hashes and inclusion/omission counts, token-aware fitting for worker and metered calls, and private manager/station chat and work-order planner input hashes recorded after each model attempt is fitted. Planner history retains requesting authority and rechecks it before applying answers. Evaluators and supervisors record fitted attempts and refuse changed authority, supplied evidence or action targets. Approved memory has immutable revisions, typed knowledge/run/pack origins and current-access checks. Approved memory refreshes per step; a preparation race requires Retry. Native station and crew runs record a prepared model input for every fitted model attempt (fallbacks included), linked to the retrieval selection it used, and recheck current authority after each answer, before each tool call and before publication; a changed card, memory, tool grant, roster or pause stops the run as superseded with no retry. Repository memory reads only the workflow's first connected repository, is pinned to that repository's identity and is withheld from outside workers | Files, issues and pull/merge requests support GitHub, GitLab and Gitea; Discussions remains GitHub-only. Gitea passed a real local-host import/lifecycle check; GitLab remains fixture-verified. No retrieval cache. Chat and planner records are prepared inputs, not provider receipts or replayable prompts. Prepared inputs are not provider receipts or replayable prompts. Outside runtimes record no prepared input; per-source lineage over the knowledge and map items in a fitted request, provider-outcome links, complete skill provenance and access-checked historical replay remain open. The acceptance check covers the card's title, description, fields and tasks, not its comments or artifacts. Each prepared-input record currently adds memory to the API process, so very long native runs use noticeably more memory than before. Repository memory has no search beyond the first 100 ready evidence sources and no explicit sharing with outside repositories; broader typed provenance and historical-copy retention remain open. Deleting a note does not erase combined historical instructions or model paraphrases. Web sources do not crawl; vendor connectors still need live-account validation |
| Static code graph | JavaScript/TypeScript, Python, Go, Java, Rust and PHP declarations and imports; module-root resolution from declared configuration; dynamic-import edges marked possible; framework routes for Next.js, Express/Koa, MasterController (routes resolved to their controller actions, with guard, beforeAction and data facts), FastAPI/Flask, Django, Spring and Laravel | C# and Ruby are not supported (no maintained parser grammar); C++ not in scope. Not inferred: tsconfig extends, Go replace, router mount prefixes, Go HTTP routers. Selected files only, not a whole-repository call graph |
| System Map | Analysis on connect into typed module, service, endpoint, data, external-system, queue, test, runtime and pattern nodes over the static code graph and the repository's deployment descriptors, with progress read from rows and a time-left estimate labelled as one, a ready that is never partial, no file cap (measured to 250,000 files), default excludes, monorepo packages with a picker, per-organization fairness and rate-limit waits; incremental updates on push and merge through webhooks CodeBook registers and repairs; a version per commit; five list views, an Ask tab, a Docs tab with Markdown export and pull-request write-back, and a node sheet; organization nodes written by administrators and factory objects placed by rule; production incidents and deploys from six kinds of monitoring source, linked by mapping or exact name; a ranked, recorded context pack with per-run measurement and an optional holdout; impact levels from written thresholds, level-conditioned routes and approval, and work snapshots | Outside systems only from imports (no hostnames or environment variables); data writes not derived; a push reads only the changed files but the rule phases re-read the whole stored graph; builds past 250,000 files run but are unmeasured; a single provider response (a GitHub tree listing, a GraphQL batch) is parsed whole; Gitea reads file by file. Deploys come only from the generic webhook and GitHub's deployment_status; MadeBook violations are not counted by impact analysis; the monitoring adapters are written and tested against each provider's documented payloads, not deliveries from live provider accounts. Docs: incident signals on cards are not listed on pages, prose is not re-asked when only the model changed, and each write-back opens a new pull request. Crews now retain separate participant packs and call usage, but remain excluded from job-level savings comparisons; the measurement reads citations only in a run's final answer, and a holdout never switches the engine off or on. The snapshot line is not in the card view. The OpenBook product feed and MadeBook governance feed are released in all three products but have not yet been exercised end to end between linked production workspaces. Ask and the optional context re-rank need a tool-capable model at SSO and have not been run against a real model in production; docs prose needs the organization's model, and without one the docs are the facts alone |
| Contracts, artifacts and events | Station contracts, typed text/link artifacts, signed webhooks and a database-backed event bus. Runner recordings, traces, screenshots, logs and reports use SSO file storage; real local recording/log upload, download and card playback passed | No external schema import into contracts, signed typed approvals or external queue-broker adapter. Runner files are separate from typed card artifacts. Runner 1.5.1 passed real Podman isolation, networking, timeout cleanup and stopped-engine checks |
| Realtime presence | Presence on a workflow | An "is editing" marker on the card dialog, a typing indicator on comments, and suppressing notifications for someone already present are not built |
Verification still matters
The latest app release passed its backend suite, production frontend build and authorization coverage check. An authenticated local walkthrough used real SSO and MinIO with a scripted model to exercise crews, evaluator review, two-person canary approval/comparison/stop, CSV-to-ticket chat, the worker SDK lifecycle and runner recording upload/download/playback. Manager model settings, permissions and editor/Studio links were also checked in a browser. These checks establish runtime behavior, not model quality or every production integration.
The earlier migrations 102–105 were not rehearsed on PostgreSQL before merge; their recorded evidence is successful production startup through the migration gate. Migrations 106–107, gate/planner 111–112, memory/reviewed-pack 113–114, repository memory 116, model-policy definition 117 and prepared-input retrieval links 118 passed fresh and populated PostgreSQL rehearsals through the production schema pipeline. Preservation and concurrency checks cover the changed records. Representative real-PR scorer agreement, real-provider quality and production SDK validation remain open. Vendor integrations without live accounts were tested against stand-ins, as the table describes.
Before relying on a deployment, verify sign-in, permissions, required migrations/indexes, a tool-capable organization model, a repository connection and the tool credentials your workflow needs.
The next data-plane work
CodeBook already has durable scoped memory, indexed knowledge, immutable skill packages, runs, artifacts, scoring, evaluations and factory versions. The next work connects those existing pieces more consistently; it is planned, not a newly shipped unified data-plane service.
- Define shared ownership, revision, retention and retrieval contracts over existing records.
- Extend prepared input records to outside runtimes, with per-source lineage, complete skill provenance, provider-outcome links and access-checked replay. Native and crew runs now record theirs.
- Extend reviewed memory revisions with broader evidence types, exact later-use links and historical-copy retention. Repository scope has shipped.
- Add reviewed memory, skill and retrieval-change proposals to the observer, with evaluation and explicit release.
- Complete factory export/version coverage (model policies are now covered; worker policies, skill releases, knowledge revisions, tool grants and runtime bindings are not) and reproducible replay of configuration and dependencies.
Real-task measurement runs alongside these changes. Manager role fixtures and human judgments now have separate evidence surfaces. Real-provider quality calibration, real-PR scorer agreement and production SDK validation remain separate work. Runner 1.5.1 passed real Podman checks for writable checkout/cache, host-home and environment isolation, network off/on, timeout cleanup and stopped-engine refusal. No percentage of architectural completeness or unmeasured reliability claim is implied.
Deliberately outside this scope
Marketplace star ratings, install-count displays and certified badges; paid marketplace/revenue sharing; and VPC, on-premises or air-gapped packaging are excluded. Operational token usage, spending derived from SSO model prices and evidence-based outcomes are supported. CodeBook publishes no model price table and bills nobody itself.
Organizations, membership, shared identity, model-provider credentials and platform billing belong to SSO. CodeBook consumes those services rather than duplicating them.