Cambium
KimGLee · KimGLee/Cambium
Cambium is a governance standard and reference toolset for LLM-maintained knowledge corpora, helping operators manage rules, work, and evidence.
Governance standard and reference toolset for LLM-maintained knowledge corpora
Preview
What you can do with it
- Establish clear governance rules for an LLM-maintained knowledge base.
- Define required evidence before an agent's knowledge-related work can close.
- Resume an interrupted task on a knowledge repository without losing context.
Safety check
Usable, but read the notes first.
- ●No clear license: check with the author before using it in a commercial product.
Automated scan of the repo files. Always review code you run.
From the README
Cambium
English | 简体中文
Cambium is a governance standard and reference toolset for knowledge repositories maintained with LLM agents.
It helps an operator answer five practical questions:
- What rules apply to this repository?
- What work is required, and who may change shared state?
- What evidence must exist before work can close?
- How can an interrupted task resume without guessing?
- Which decisions belong to the operator rather than the agent?
Cambium is not a knowledge base, a RAG engine, an agent scheduler, or a default domain policy. It governs work; it does not supply the corpus or decide its meaning.
Start Here
- To understand the model, read The Mental Model.
- To adopt Cambium for a repository, follow Adopt Cambium.
- To resume existing work, run the command in Start Or Resume A Task before writing anything.
- To connect an agent host, see Use Cambium From An Agent Host.
- For every tool and its exact arguments, see Tools/README.md.
- For what is complete, in progress, or only conditional, see ROADMAP.md.
The Mental Model
effective governance
= Cambium kernel
+ exactly one selected profile
+ adopter-owned runtime state
The diagram shows how these layers connect to runtime routes, deterministic tools, and agent execution contexts.
| Layer | What it owns |
|---|---|
kernel/ | Cross-domain governance semantics, invariants, state meanings, and extension points |
Card/ | Curated, non-authoritative flight checklists for an already selected task route or phase |
Read Set/ | Machine-resolvable declarations of what canonical material an already selected route or phase must load |
| Selected profile | One repository's scope, language, architecture, sources, priorities, roles, scans, and allowed extensions |
.cambium/ | The adopter's current governance identity, task state, Queue, plans, deltas, receipts, and recovery evidence |
Tools/ | Stable public commands and Area/Domain implementations for deterministic checks, controlled writes, schemas, and generated projections |
The kernel is normative. A profile can fill or tighten an extension point, but cannot disable a kernel rule. Tools execute declared rules; they do not make the final semantic judgment.
Cards are short, curated checklists, not routes or a second copy of the standard. Read Sets own the static loading boundary. When a Card is insufficient or disputed, its read-back hook resolves through the paired Read Set to the canonical owner.
This repository is intentionally uninstantiated. It contains one candidate Profile template and non-authoritative examples, but selects no adopter profile and creates no fabricated task state.
What Ships Today
Cambium currently provides:
- one empty TOML Profile candidate, Agent-assisted interviews, safe creation and snapshot-bound editing tools, read-only review/status views, and CUE-backed Profile checks;
- persistent Coverage, Required Queue, and Progress state for resumable work;
- deterministic task and batch transitions, controlled Amendments, active-task Standards adoption, interruption recovery, and build or maintenance closure;
- append-only receipts and Terminal Proof bindings;
- explicit Global Map, Capability Matrix, and Gap Register validation;
- deterministic page, structure, vocabulary, link, boundary, freshness, and residual-content checks;
- a generated host-neutral interface: each tool's own CLI declaration and the closed agent-interface capability policy compile into the agent-facing MCP projection and per-host configuration; every active caller-visible path is retained as a descriptor capability through subprocess consumption;
- a typed Task Runtime Runner that advances registered deterministic tools to the next Agent, user, Host, repair, or terminal boundary;
- Card-first activation and progressive Read Set delivery primitives.
The generated MCP surface exposes both leaf calls and the bounded Runner. The Runner is not a scheduler or governance engine: it derives one identity-bound next action from current runtime state, invokes only registered capabilities, reads the result back, and stops at every semantic boundary. Each underlying Tool still decides whether its operation is valid and whether its evidence counts. For every active typed path, the transport retains the admitted file or parent-directory descriptor through subprocess consumption; an unsupported platform fails server initialization instead of claiming this assurance.
What Does Not Ship Yet
Cambium 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 arbitrary concurrent mutation;
- automatic corpus-wide dependency propagation;
- an independent evaluator that re-derives the complete expected corpus;
- an installable OpenAI Plugin package, Hooks, UI, or marketplace entry.
These boundaries are intentional. A host may add capabilities, but it must not claim evidence for a capability it cannot prove. See ROADMAP.md for the delivery order.
The Three Runtime Ledgers
Long-running work uses three state objects with different owners:
| State object | What it answers |
|---|---|
| Coverage Ledger | Which knowledge objects exist, what disposition they have, and which batch currently owns unfinished work? |
| Required Queue | Which batches exist, what are their manifests and dependencies, and what lifecycle state is each batch in? |
| Progress Ledger | What is the task contract, whole-task state, checkpoint, Standards identity, and accepted Queue fingerprint? |
They must agree, but they are not interchangeable task lists.
The adopter-owned namespace contains six lifec