Cambium: A Governance Standard for LLM Corpora

LLM knowledge corpus governance is a problem almost nobody had two years ago and quite a few teams have now: an agent maintains your documentation, your internal wiki, your product knowledge base, and after six months nobody can say which parts were verified against a source, which were inferred, and which quietly drifted.

Cambium is an attempt to write the rulebook for that, and it is the first project I have seen treat LLM knowledge corpus governance as a standard rather than a feature. It defines how an agent loads rules, scopes its work, preserves who owns which knowledge object, incorporates sources, manages long-running changes, and produces auditable evidence before it's allowed to claim a job is done.

What it deliberately isn't: a corpus, a RAG engine, or a set of domain policies. KimGLee/Cambium went up on August 4, 2026 and had 208 stars by August 10, a new repository moving fast for something this abstract.

Key Takeaways:

• The formula is effective standard = domain-neutral kernel + exactly one selected profile. The kernel holds cross-domain rules; a profile supplies one corpus's specifics and cannot weaken the kernel.
• The repository ships intentionally uninstantiated. No profile is selected, governance placeholders are unfilled, and no fabricated state is distributed. You cannot simply run it.
• Licensing is per-path: tooling under Tools/ is Apache-2.0, while the specification and documentation are CC BY 4.0. GitHub reports the repo as NOASSERTION because of that split.
• Work units are batches with their own manifests, dependencies, receipts and lifecycle, ordered by a persistent, model-neutral Required Queue.
• The tools do deterministic checks and controlled state writes. The README is explicit that they are not the final semantic judgment.

What Cambium is

A standard first, a toolset second, and the ordering is deliberate.

Kernel modules K00 through K13 carry the normative rule text, cross-domain and non-negotiable. Runtime routes R01 through R13 are task-specific loading and execution paths, in a separate namespace. Read Sets bound which sources a route may load. Runtime Cards are compiled shortcuts for routine execution, and the README is careful to say they are never a second source of rules; when a card is incomplete or disputed, the agent reads back its Read Set and the referenced kernel modules, because normative source text always wins.

The adopter side lives in .cambium/: coverage state, the canonical Required Queue, task-level progress, hash-bound work specs for complex batches, controlled plans, deltas, receipts and derived reports.

Two kernel modules carry most of the weight. K02 owns knowledge-object inventory, coverage semantics, corpus planning, architecture and dependency planning, batch production and migration safety. K13 owns the persistent runtime namespace, the task contract, the progress ledger, the Required Queue, batch transitions, completion bindings, handoff and interruption recovery. The boundary between them keeps "what knowledge exists and who owns it" separate from "what work is in flight," while requiring the two to reconcile.

If that reads like a standards document rather than a README, it is one.

Why LLM-maintained knowledge corpora need governance

The failure mode isn't dramatic, which is exactly why it goes unnoticed for months.

An agent updating a knowledge base does small, plausible things: rewrites a section for clarity, merges two overlapping pages, adds a fact it inferred from a related document, updates a figure it read somewhere. Each edit looks fine. Over hundreds of edits the corpus stops matching reality, and there is no diff you can point at, because every individual change was reasonable. The provenance is gone, the ownership is muddled, and the only honest answer to "is this page still true" is "somebody would have to check."

Cambium's answer is to make completion a claim requiring evidence. A batch produces receipts. A knowledge object has canonical ownership that survives edits. Work is scoped before it starts and reconciled after. Deltas exist as artefacts rather than as a memory of what happened.

The instinct behind it matches what Semantica is doing on the provenance side of agent context, from the other direction: Semantica builds the graph and tracks where each fact came from, while Cambium governs the process that lets an agent change what's in the corpus at all. Both are betting that the interesting problem in 2026 isn't retrieval quality, it's accountability. Neither replaces the day-to-day discipline of context engineering for agents; they sit above it, deciding what an agent is allowed to write down and what it must prove first.

How Cambium handles audit and provenance

Batches, receipts and a queue, described more formally than most production systems bother with.

A batch is an independently accepted unit of work carrying its own manifest, dependencies, receipts, delta and lifecycle. The Required Queue is the persistent, model-neutral owner of those manifests, holding their deterministic order, dependencies, holds and lifecycle. An agent is just an execution context assigned to work, which is the neatest idea in the whole design: the queue outlives the agent. Swap the model, restart the session, hand off to a different runtime, and the work state is unaffected because it never lived in the agent.

Interruption recovery follows from that, and so does handoff. K13 owns both, along with the progress ledger and completion bindings.

Hash-bound work specs matter for the complex batches: the spec is tied to a hash, so an agent cannot quietly redefine the job it was given halfway through and then declare it finished. That's a specific defence against a specific agent behaviour, and it suggests the author has watched it happen.

The tools do deterministic checks, controlled state writes, schema validation, receipt generation and artefact compilation. What they don't do is decide whether the knowledge is any good. The README says so directly, which is more honest than the alternative of implying a linter can judge truth.

The uninstantiated problem

Here's the thing to understand before you clone it.

The repository "is intentionally uninstantiated." Governance placeholders in K00/03 Standards Governance are unfilled, no profile is selected, and it distributes no profile-specific vocabulary file or fabricated .cambium/state/. In other words it defines no active standard for any particular corpus. That is a deliberate and defensible choice, since a governance standard shipped with someone else's domain policy baked in would be worse than useless. It also means adoption starts with you writing a profile: your scope, language, architecture, corpus-planning bindings, scale, priorities, sources, roles, artefacts, audit bindings, scans and supplemental gates.

That is not an afternoon. It's the same shape of work as writing an ontology, and the same reason most knowledge-graph projects stall before they start. Anyone who has filled in a SHACL shapes file for a real domain will recognise the feeling, and LLM knowledge corpus governance asks for the process version of that exercise on top.

So the realistic read: Cambium is a specification worth reading if you're building this kind of system, whether or not you adopt the toolset. Fourteen kernel modules of considered rules about how an agent should be allowed to touch a corpus is a useful artefact by itself, and at 208 stars in six days somebody agrees. Whether anyone completes a full profile and runs it in anger is the open question, and there's no public example yet.

Reading it as a design document instead of a dependency

Most people who find this repository will not adopt it, and can still take three things from it.

The first is the queue-outlives-the-agent principle. Anywhere you have agents doing long work, putting the work state in something model-neutral and persistent, rather than in the agent's session, buys you interruption recovery and handoff for free. That idea costs nothing to copy and it is the difference between a workflow that survives a crash and one that starts over.

The second is hash-bound work specs. If an agent can restate its own task, it will eventually declare victory over a job it redefined to be easier. Binding the spec to a hash makes that visible.

The third is the refusal to let tooling render semantic judgment. Deterministic checks catch structural violations, and nothing automated tells you whether a paragraph is true. Systems that blur this line produce green dashboards over rotting content, which is the exact failure LLM knowledge corpus governance is supposed to prevent.

None of that requires fourteen kernel modules. It requires deciding, before you point an agent at your documentation, what evidence you will demand before believing it finished.

FAQ

Is Cambium open source?

Yes, with licences assigned by path, which is why GitHub's API reports NOASSERTION rather than a single identifier. Software and implementation material under Tools/ is Apache-2.0. The specification, documentation and roadmap are CC BY 4.0. The repository's LICENSE.md holds the authoritative scope.

What is knowledge corpus governance?

Rules covering how a body of knowledge may be changed, by whom, with what evidence, and how those changes are recorded. Applied to LLM agents it means scoping work before it starts, preserving canonical ownership of each knowledge object, requiring sources to be incorporated rather than paraphrased from memory, and producing receipts before an agent may declare completion.

Can I install and run Cambium today?

Not without work. The repository is intentionally uninstantiated: no profile is selected and the governance placeholders are unfilled, so it defines no active standard for any specific corpus. Adopting it means authoring a profile covering your scope, sources, roles, audit bindings and gates first.

Does Cambium include a RAG engine or a knowledge base?

No, and it says so in its opening paragraphs. It provides no corpus, no retrieval engine and no default domain policy. It governs how an operator and an agent maintain a corpus that already exists.

What is the kernel-and-profile split for?

To let one standard serve many domains without being weakened. The kernel holds normative cross-domain rules; a profile supplies one corpus's concrete answers. A profile may extend defined interfaces but cannot replace, disable or weaken the kernel, so adopting Cambium for a lax domain can't quietly strip the guarantees out of it.