Cambium

English | 简体中文

Cambium is a governance standard and reference toolset for knowledge corpora maintained with LLM agents. It defines how an agent loads rules, scopes work, preserves canonical ownership, incorporates sources, manages long-running changes, and produces auditable evidence before claiming completion.

Cambium does not provide a knowledge corpus, a RAG engine, or a default domain policy. It governs how an operator and an agent maintain a corpus over time.

Architecture

effective standard = domain-neutral kernel + exactly one selected profile

The kernel owns the cross-domain rules. A profile supplies one corpus's concrete scope, language, architecture, corpus-planning bindings and scale, priorities, sources, roles, expression artifacts, audit bindings, scans, and supplemental gates. A profile may extend defined interfaces, but it cannot replace, disable, or weaken the kernel.

Within the kernel module namespace, K02 Knowledge Work Construction owns knowledge-object inventory, Coverage semantics, Corpus Planning, architecture and dependency planning, knowledge-batch production, and migration safety. K13 Task Runtime and Execution Control owns the persistent runtime namespace, Task Contract and task state, Guidance/Amendments, Progress Ledger, Required Queue, batch transitions, hash-bound batch Work Specs, controlled active-task Standards-adoption state writes, completion bindings, handoff, and interruption recovery. K12 remains the sole owner of which changed Standards predicates affect a live task and which gates must rerun. This boundary keeps knowledge-object disposition separate from batch/work-unit lifecycle while requiring the two state layers to reconcile.

Routine work starts from Runtime Cards. When a Card is incomplete, disputed, or insufficient for an exception, the agent reads back its Read Set and the referenced kernel modules. Normative source text always wins.

This repository is intentionally uninstantiated. The adopter-specific active state in K00/03 Standards Governance still contains placeholders and no profile is selected. It therefore defines no active standard for a particular knowledge corpus and distributes no profile-specific Tools/vocab.yaml or fabricated .cambium/state/.

Execution Model

Cambium separates durable work units from execution contexts.

• A batch is an independently accepted unit of work with its own manifest, dependencies, receipts, delta, and lifecycle.
• The Required Queue is the model-neutral, persistent owner of those batch manifests, their deterministic order, dependencies, holds, and lifecycle.
• An agent is an execution context assigned to work. One agent may execute several batches sequentially, while isolated agents may execute disjoint batches concurrently.
• A subagent is a child execution context created by a runtime. It is not a separate Cambium work unit or authority class and may act as a worker, researcher, or independent reviewer. Acting as the independent reviewer is the narrowest of those roles: K12/12 Substantive Correctness Review requires a subagent started with a clean context and carrying no author context, whose input is only the note body and its Sources. An ordinary child context that inherits the author's context does not satisfy it.
• A logical integrator exclusively controls the shared state named in K13/10 Batch Admission Transitions and Serial Integration: guidance disposition, Queue structural revision, Queue state transition, contract changes, Standards adoption, batch activation, and merging. That module states the enumeration; this list is a reader's summary of it.

The active-batch concurrency limit is not an agent-count limit. Concurrent workers produce isolated batch outputs; the integrator merges those outputs one at a time and runs the global checks after each merge.

Three machine-readable control objects deliberately have different jobs:

They are reconciled rather than treated as interchangeable task lists.

Repository Layout

The included Agent Systems Atlas profile is an example of answer shape and specificity. It is not Cambium's default configuration and does not contain the Atlas knowledge corpus.

Adopter Runtime State

Long-running, resumable, or multi-batch work uses one fixed namespace in the adopting repository. Every task first checks whether that namespace already exists, because a seemingly bounded new request may enter a repository whose earlier persistent task was interrupted:

.cambium/
├── state/       # Coverage, Required Queue, and Progress
├── work_specs/  # immutable restricted-YAML contracts for complex batches
├── deltas/      # worker deltas and restricted-YAML controlled-operation plans
├── receipts/    # deterministic and transition evidence
├── reports/     # derived human-readable views
└── tmp/         # recovery locks and incomplete-write metadata

state/, work_specs/, deltas/, and receipts/ are durable. Reports are projections, not tool inputs, and tmp/ is ignored by Git; a surviving writer lock remains recovery evidence until its operation is reconciled. Cambium publishes the schemas under Tools/schemas/; a conformance fixture suite is planned rather than shipped, and this repository carries none today (see ROADMAP.md Observability And Conformance). An adopter creates its own runtime state with Tools/init_state.py after selecting a profile and defining a task. The tool requires an explicit objective and exclusions, does not invent Required work, and does not overwrite any existing .cambium/ namespace. If the namespace already exists, a restarted or newly assigned Agent first runs Tools/check_queue.py . --resume-status to discover the recorded task, its build or maintenance completion semantics, checkpoint binding, latest task transition, in-flight batches, pending control inputs/deltas, the applicable completion block, maintenance candidate SHA/partition and prior completion anchor, holds, writer-lock evidence, and the exact machine-readable next_action. A complete open-batch handoff is reported as admit-delta; a merge-ready batch without an apply receipt becomes apply-delta, and an applied batch without a current close bundle becomes run-batch-close-gate. Only a current bundle authorizes the four-ID close-applied-batch action and its exact copyable close command. This prevents a fresh Agent context from mistaking an interrupted repository for an unused one.

Current Implementation Boundaries

The kernel and tools now provide persistent task and Required Queue state, optional hash-bound complex-batch Work Specs, explicit Global Map / Capability Matrix / Gap Register validation, and deterministic initialization, compilation, validation, task/batch transitions, active-task Standards/Profile adoption, interruption recovery, build Terminal closure, bounded maintenance closure, and derived report generation. The page-level contract family is also deterministic: the composed frontmatter page contract (K08/06-08, advisory page-contract gate), the Structure Registry resolution (K01/05-06, structure-registry gate) with its marker-block coverage projections, and the page boundary contract (K08/09, adv