Cambium: a governance standard for knowledge repositories maintained by LLM agents

The problem Cambium governs

When LLM agents maintain a shared knowledge repository, the hard questions are not about retrieval but about control: what rules apply, who may change shared state, what evidence must exist before work closes, how an interrupted task resumes without guessing, and which decisions belong to the human rather than the agent. Cambium is a governance standard and reference toolset aimed squarely at those five questions. It is careful about what it is not: not a knowledge base, not a RAG engine, not an agent scheduler, and not a default domain policy. It governs the work and its evidence; it does not supply the corpus or decide what the content means. The audience is operators running agent-maintained documentation or knowledge corpora who need auditability and human-in-the-loop control rather than another retrieval library.

Kernel, profile and runtime state

The model is a layered one, stated as a formula in the README:

effective governance
  = Cambium kernel
  + exactly one selected profile
  + adopter-owned runtime state

The kernel is normative and its rules cannot be disabled; a profile can fill or tighten an extension point for one repository's scope, language, roles and allowed extensions, but it cannot override a kernel rule. The adopter's runtime state lives in a .cambium directory holding the governance identity, task state, queue, plans, deltas, receipts and recovery evidence. Around these sit deterministic tools that execute declared rules without making the final semantic judgment, and short curated checklists called Cards whose read-back hooks resolve through Read Sets to the canonical owner. The separation is the point: rules are normative, tools are mechanical, and the human keeps the semantic decisions.

The three runtime ledgers

Long-running work in Cambium is tracked by three state objects with distinct owners, and the design insists they agree without being interchangeable. The Coverage Ledger records which knowledge objects exist, their disposition, and which batch owns unfinished work. The Required Queue records which batches exist, their manifests and dependencies, and each batch's lifecycle state. The Progress Ledger holds the task contract, the whole-task state, the checkpoint, the standards identity and the accepted queue fingerprint. Together they answer the resume question: an interrupted task can pick up from recorded state rather than guessing, and append-only receipts plus terminal-proof bindings mean a closed piece of work carries its evidence. This is the concrete machinery behind the governance claims, and it is why Cambium calls itself a standard with a reference toolset rather than a single program.

Adopting Cambium for a repository

Adoption is deliberate and does not happen by copying files. The repository ships intentionally uninstantiated: it contains one candidate profile template and non-authoritative examples, but selects no adopter profile and creates no task state, so cloning it does not put you under governance. To adopt, you run the authoring workflow from a Cambium source checkout after the documented host preparation, which creates and approves exactly one profile for your repository. Connecting an agent host is a separate step: Cambium generates a host-neutral interface, compiling each tool's own declaration into an agent-facing MCP projection and per-host configuration, so an MCP-capable agent can call the registered tools and a typed runner advances them to the next boundary. The exact tool arguments live in the Tools documentation rather than being duplicated in the README, which is consistent with the project's single-source discipline.

What does not ship yet

Cambium is unusually explicit about its boundaries, and that candor is the honest limitation. The README lists what it does not currently bundle: agent dispatch or scheduling, isolated worker workspaces, a complete single-writer integrator loop, durable assignment lifecycle management, authenticated actor or reviewer identity, protected whole-workspace execution against concurrent mutation, automatic corpus-wide dependency propagation, an independent evaluator that re-derives the expected corpus, and an installable plugin package or UI. Those are real gaps for anyone imagining a turnkey system. The project frames them as intentional and points to a roadmap for delivery order, and it states that a host may add capabilities but must not claim evidence for one it cannot prove. The NOASSERTION on its license is a further caveat, since it signals a non-standard license you must read before relying on it.

Cambium versus governance by prompt

The common alternative is informal governance: a CLAUDE.md or a set of prompt rules telling the agent how to behave, enforced only by the model's willingness to follow them. That is easy to start and needs no toolset, but it has no deterministic check, no ledger, and no proof that work actually met its rules, so an agent can quietly drift. Cambium's difference is that its tools execute declared rules mechanically and its ledgers and receipts record what happened, so closure is gated on evidence rather than on trust. The cost is real setup: a selected profile, host preparation and a heavier mental model than a prompt file. For a small repository, prompt-based rules may be enough; for a knowledge corpus where auditability and safe resumption actually matter, Cambium is trying to make governance verifiable rather than aspirational.

A non-standard license and current status

Cambium's license shows as NOASSERTION, meaning a non-standard or unrecognized license rather than a clear open source grant, so read LICENSE.md before you build on it or redistribute it. The last push was on 2026-09-12, and the project is bilingual, shipping English and Chinese READMEs and roadmaps. The status to internalize is that this is a standard plus a reference toolset with clearly marked in-scope and out-of-scope capabilities, not a finished platform, and the roadmap defines the delivery order for the parts that do not ship yet. Treat what the README lists under what ships today as the real surface, verify the license, and expect to do genuine adoption work rather than an install, since the repository deliberately arrives uninstantiated.

Editorial conclusion

Adopt Cambium if you run a knowledge corpus maintained by LLM agents and need verifiable governance: deterministic rule checks, evidence-gated closure and resumable state, with humans keeping the semantic decisions. Do not expect a turnkey platform, since agent scheduling, worker isolation and a plugin package are explicitly not shipped yet, and read LICENSE.md first because the license is non-standard. Start by reading the ROADMAP to confirm the parts you need are in scope, then run the authoring workflow from a source checkout to create one profile.

Frequently asked questions

Official sources

1. Issues
2. KimGLee/Cambium on GitHub
3. README