[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-94344":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":14,"stars7d":14,"stars30d":15,"stars90d":14,"forks30d":14,"starsTrendScore":14,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":14,"starSnapshotCount":14,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},94344,"Cambium","KimGLee\u002FCambium","KimGLee","Governance standard and reference toolset for LLM-maintained knowledge corpora",null,"Python",208,7,117,0,73,50.01,"Other",false,"main",true,[],"2026-08-24 04:01:22","# Cambium\n\nCambium is a governance standard and reference toolset for knowledge corpora\nmaintained with LLM agents. It defines how an agent loads rules, scopes work,\npreserves canonical ownership, incorporates sources, manages long-running\nchanges, and produces auditable evidence before claiming completion.\n\nCambium does not provide a knowledge corpus, a RAG engine, or a default domain\npolicy. It governs how an operator and an agent maintain a corpus over time.\n\n## Architecture\n\n```text\neffective standard = domain-neutral kernel + exactly one selected profile\n```\n\nThe kernel owns the cross-domain rules. A profile supplies one corpus's\nconcrete scope, language, architecture, corpus-planning bindings and scale,\npriorities, sources, roles, expression artifacts, audit bindings, scans, and\nsupplemental gates. A profile may extend defined interfaces, but it cannot\nreplace, disable, or weaken the kernel.\n\n| Component | Responsibility |\n|---|---|\n| Kernel modules (`K00`-`K13`) | Normative, cross-domain rule text |\n| Runtime routes (`R01`-`R13`) | Task-specific loading and execution paths; `Kxx` and `Rxx` are independent namespaces |\n| Read Sets | Route-specific source-loading boundary used when a Runtime Card requires read-back |\n| Runtime Cards | Kernel-owned, compiled shortcuts for routine agent execution; never a second source of rules |\n| Selected profile | The adopter's concrete answers to the profile interface |\n| Adopter runtime namespace (`.cambium\u002F`) | Coverage object state, the canonical Required Queue, task-level Progress, hash-bound complex-batch Work Specs, controlled plans including active-task Standards adoption, deltas, receipts, and derived reports |\n| Tools | Deterministic checks, controlled state writers, schemas, receipts, and derived\u002Fcompiled-artifact generators; not final semantic judgment |\n\nWithin the kernel module namespace, [K02 Knowledge Work Construction](\u003Ckernel\u002FK02 Knowledge Work Construction Standard.md>)\nowns knowledge-object inventory, Coverage semantics, Corpus Planning,\narchitecture and dependency planning, knowledge-batch production, and\nmigration safety. [K13 Task Runtime\nand Execution Control](\u003Ckernel\u002FK13 Task Runtime and Execution Control Standard.md>)\nowns the persistent runtime namespace, Task Contract and task state,\nGuidance\u002FAmendments, Progress Ledger, Required Queue, batch transitions,\nhash-bound batch Work Specs, controlled active-task Standards-adoption state\nwrites, completion bindings, handoff, and interruption recovery. K12 remains\nthe sole owner of which changed Standards predicates affect a live task and\nwhich gates must rerun. This boundary keeps\nknowledge-object disposition separate from batch\u002Fwork-unit lifecycle while\nrequiring the two state layers to reconcile.\n\nRoutine work starts from Runtime Cards. When a Card is incomplete, disputed,\nor insufficient for an exception, the agent reads back its Read Set and the\nreferenced kernel modules. Normative source text always wins.\n\nThis repository is intentionally uninstantiated. The adopter-specific active\nstate in\n[`K00\u002F03 Standards Governance`](\u003Ckernel\u002FK00 Standards Control\u002F03 Standards Governance.md>)\nstill contains placeholders and no profile is selected. It therefore defines\nno active standard for a particular knowledge corpus and distributes no\nprofile-specific `Tools\u002Fvocab.yaml` or fabricated `.cambium\u002Fstate\u002F`.\n\n## Execution Model\n\nCambium separates durable work units from execution contexts.\n\n- A **batch** is an independently accepted unit of work with its own manifest,\n  dependencies, receipts, delta, and lifecycle.\n- The **Required Queue** is the model-neutral, persistent owner of those batch\n  manifests, their deterministic order, dependencies, holds, and lifecycle.\n- An **agent** is an execution context assigned to work. One agent may execute\n  several batches sequentially, while isolated agents may execute disjoint\n  batches concurrently.\n- A **subagent** is a child execution context created by a runtime. It is not a\n  separate Cambium work unit or authority class and may act as a worker,\n  researcher, or independent reviewer. Acting as the independent reviewer is\n  the narrowest of those roles: [`K12\u002F12 Substantive Correctness\n  Review`](\u003Ckernel\u002FK12 Quality Assurance\u002F12 Substantive Correctness Review.md>)\n  requires a subagent started with a clean context and carrying no author\n  context, whose input is only the note body and its Sources. An ordinary child\n  context that inherits the author's context does not satisfy it.\n- A logical **integrator** exclusively controls the shared state named in\n  [`K13\u002F10 Concurrent Batches and Merge`](\u003Ckernel\u002FK13 Task Runtime and Execution Control\u002F10 Concurrent Batches and Merge.md>):\n  guidance disposition, Queue structural revision, Queue state transition,\n  contract changes, Standards adoption, batch activation, and merging. That\n  module states the enumeration; this list is a reader's summary of it.\n\nThe active-batch concurrency limit is not an agent-count limit. Concurrent\nworkers produce isolated batch outputs; the integrator merges those outputs\none at a time and runs the global checks after each merge.\n\nThree machine-readable control objects deliberately have different jobs:\n\n| State object | Owns |\n|---|---|\n| Coverage Ledger | Knowledge objects, dispositions, canonical owners, and object-side batch assignment |\n| Required Queue | Batch\u002Fwork-unit manifests, order, dependencies, lifecycle, holds, and transition evidence |\n| Progress Ledger | Task Contract, whole-task state, Guidance\u002FAmendments, checkpoints, and the accepted Queue fingerprint |\n\nThey are reconciled rather than treated as interchangeable task lists.\n\n## Repository Layout\n\n| Path | Contents |\n|---|---|\n| [`kernel\u002F`](kernel\u002F) | Cross-domain standards, Read Sets, and compiled Runtime Cards |\n| [`profiles\u002FREADME.md`](profiles\u002FREADME.md) | The authoritative profile-slot interface and filling rules |\n| [`profiles\u002F_template\u002F`](profiles\u002F_template\u002F) | A domain-neutral form to copy and fill; not a runnable or default profile |\n| [`profiles\u002Fexamples\u002F`](profiles\u002Fexamples\u002F) | Non-normative completed references; examples are not adoption starting points and cannot be selected in place |\n| [`Tools\u002F`](Tools\u002F) | Standard-library Python checks, schemas, receipts, and compiled-artifact generators |\n| [`ROADMAP.md`](ROADMAP.md) | Non-normative implementation directions; not a statement of current capability |\n\nThe included\n[`Agent Systems Atlas`](profiles\u002Fexamples\u002Fagent-atlas\u002FREADME.md) profile is an\nexample of answer shape and specificity. It is not Cambium's default\nconfiguration and does not contain the Atlas knowledge corpus.\n\n## Adopter Runtime State\n\nLong-running, resumable, or multi-batch work uses one fixed namespace in the\nadopting repository. Every task first checks whether that namespace already\nexists, because a seemingly bounded new request may enter a repository whose\nearlier persistent task was interrupted:\n\n```text\n.cambium\u002F\n├── state\u002F       # Coverage, Required Queue, and Progress\n├── work_specs\u002F  # immutable restricted-YAML contracts for complex batches\n├── deltas\u002F      # worker deltas and restricted-YAML controlled-operation plans\n├── receipts\u002F    # deterministic and transition evidence\n├── reports\u002F     # derived human-readable views\n└── tmp\u002F         # recovery locks and incomplete-write metadata\n```\n\n`state\u002F`, `work_specs\u002F`, `deltas\u002F`, and `receipts\u002F` are durable. Reports are\nprojections, not tool inputs, and `tmp\u002F` is ignored by Git; a surviving writer\nlock remains recovery evidence until its operation is reconciled. Cambium\npublishes the schemas under `Tools\u002Fschemas\u002F`; a conformance fixture suite is\nplanned rather than shipped, and this repository carries none today (see\n[`ROADMAP.md`](ROADMAP.md) `Observability And Conformance`). An adopter creates\nits own runtime state with `Tools\u002Finit_state.py` after selecting a profile and\ndefining a task. The tool\nrequires an explicit objective and exclusions, does not invent Required work,\nand does not overwrite any existing `.cambium\u002F` namespace.\nIf the namespace already exists, a restarted or newly assigned Agent first\nruns `Tools\u002Fcheck_queue.py . --resume-status` to discover the recorded task,\nits `build` or `maintenance` completion semantics, checkpoint binding, latest\ntask transition, in-flight batches, pending control inputs\u002Fdeltas, the\napplicable completion block, maintenance candidate SHA\u002Fpartition and prior\ncompletion anchor, holds, writer-lock evidence, and the exact\nmachine-readable `next_action`. A complete open-batch handoff is reported as\n`admit-delta`; a merge-ready batch without an apply receipt becomes\n`apply-delta`, and an applied batch without a current close bundle becomes\n`run-batch-close-gate`. Only a current bundle authorizes the four-ID\n`close-applied-batch` action and its exact copyable close command. This prevents\na fresh Agent context from mistaking an interrupted repository for an unused\none.\n\n## Current Implementation Boundaries\n\nThe kernel and tools now provide persistent task and Required Queue state,\noptional hash-bound complex-batch Work Specs, explicit Global Map \u002F Capability\nMatrix \u002F Gap Register validation, and deterministic initialization,\ncompilation, validation, task\u002Fbatch transitions, active-task Standards\u002FProfile\nadoption, interruption recovery, build Terminal closure, bounded maintenance\nclosure, and derived report generation.\nThey do not dispatch agents. Worker dispatch, workspace isolation, event\ndelivery, and the integrator loop must still be supplied by the adopting\nruntime or a human operator.\n\nThe shipped Amendment interface first registers an approved operational\ndecision against the exact current state, then consumes that authorization in\na scope\u002Fdisposition replan or batch-cancellation transaction. Pending\nregistration receipts authorize current execution; after verified write-back\nthey prove history only. A separate Standards-adoption transaction synchronizes\nonly the three Standards\u002FProfile identities, the Progress load set, and the\nstructural Queue revision while preserving the task and every batch\nlifecycle\u002Fhold. After\nQueue materialization, a change to any other Task Contract field is rejected\nunless a host supplies an equivalent controlled writer; the\nbaseline recovery path is to pause or cancel the current task, preserve its\nruntime, and begin a successor task. A generic non-scope Contract Amendment\nwriter remains roadmap work.\n\nThese writers accept only the current public schema and receipt protocols. An\nexisting adopter runtime with older or unregistered operational Amendment\nstate must be converted outside the public execution path before it is loaded;\nStandards adoption does not guess or silently upgrade that state.\n\nProfile setup is also manual and file-based. Users copy `_template`, fill the\nresulting profile, and validate it with `check_profile.py`; this release does\nnot include a profile questionnaire or configuration generator. Planned\nconvenience and runtime layers are described in [`ROADMAP.md`](ROADMAP.md).\n\nCambium's receipts and Terminal Proof operate inside the adopting repository's\nlocal trust boundary. The shipped checks can validate receipt structure,\ndeclared producer and version labels, exact SHA-256 bindings to current state\nand content, transition-chain agreement, and whether evidence is stale. Those\nhashes are integrity bindings, not signatures: without an external signing or\ncontrolled-execution system, Cambium does not authenticate which executable\nran, which operating-system account supplied an actor label, or whether the\nrecorded reviewer was a different person or process. An adversary who may\nrewrite the repository, its tools, and its evidence can construct an\ninternally consistent history. The baseline therefore detects accidental\ndrift, incomplete transitions, and stale or inconsistent evidence; stronger\nprovenance requires controls outside this repository.\n\n## Adopt Cambium\n\nProfile adoption follows the same process whether the target corpus already\nexists or will be built from zero; Cambium does not create the corpus during\nsetup. Start by creating a profile for that corpus. Do not edit the shared\ntemplate in place and do not copy an example as the starting point.\n\n```text\ncp -R profiles\u002F_template profiles\u002Fmy-profile\n```\n\n1. Replace every `TODO(profile)` in `profiles\u002Fmy-profile\u002F`. Keep `profile_id`\n   equal to the directory name and use\n   [`profiles\u002FREADME.md`](profiles\u002FREADME.md) as the interface authority.\n2. Validate the filled copy:\n\n   ```text\n   python3 Tools\u002Fcheck_profile.py profiles\u002Fmy-profile\n   ```\n\n3. Perform initial adoption through the full\n   [`R09 Standards Governance Read Set`](\u003Ckernel\u002FRead Sets\u002FR09 Standards Governance Read Set.md>).\n   Record the adopter's Standards version, status `approved`, effective date,\n   and exact `profiles\u002Fmy-profile\u002Fprofile.md` path in K00\u002F03. Directory presence,\n   profile discovery, an example, or a generated file never selects a profile.\n4. With those candidate state fields in place, compose the profile vocabulary\n   and regenerate the Runtime Cards for the adopted Standards version:\n\n   ```text\n   python3 Tools\u002Fcompose_vocab.py\n   python3 Tools\u002Fstamp_cards.py . --set-version YOUR_VERSION\n   python3 Tools\u002Fstamp_cards.py . --check\n   ```\n\n5. Complete the R09 governance gates before beginning corpus-content work.\n   [`Tools\u002FREADME.md`](Tools\u002FREADME.md) documents the individual commands,\n   receipts, and exit semantics; tool success alone is not proof that the\n   complete governance gate passed.\n\nCopying, filling, validating, or recording a manifest path does not activate a\nprofile by itself. The manifest becomes the selected profile for content work\nonly when the complete R09 initial-adoption change closes. Validate the filled\ncopy, not `_template`; the composed vocabulary does not exist before adoption.\n\n## Adopt A New Standards Version Into An Active Task\n\nR09 governs the Standards revision and records its exact changed predicates.\nWhen an existing `.cambium\u002F` task still freezes the prior Standards\u002FProfile\nidentity, R09 produces one restricted-YAML plan using\n[`Tools\u002Fschemas\u002Fstandards_adoption_plan.template.yaml`](Tools\u002Fschemas\u002Fstandards_adoption_plan.template.yaml):\n\n```text\n.cambium\u002Fdeltas\u002Fstandards-adoptions\u002F\u003Cadoption-id>.yaml\n```\n\nThat plan is the task's canonical machine revision record. It binds the\ncomplete approved K00\u002F03 bytes, deterministic after snapshots of `kernel\u002F` and\nthe selected Profile directory, and the exact changed-predicate,\ninvalidated-evidence dimension\u002Fboundary, and rerun scope. There is no second\nrevision YAML or prose adoption copy.\n\nR07 executes or resumes that plan. Dry-run first; only the integrator writes:\n\n```text\npython3 Tools\u002Fadopt_standards.py . \\\n  --plan .cambium\u002Fdeltas\u002Fstandards-adoptions\u002FSA-001.yaml\n\npython3 Tools\u002Fadopt_standards.py . \\\n  --plan .cambium\u002Fdeltas\u002Fstandards-adoptions\u002FSA-001.yaml \\\n  --apply --actor-role integrator\n```\n\nThe writer accepts only an `active` or `paused` task. If a build task is already\n`completion-candidate`, first use the legal Task transition to return it to\n`paused` or `active`; if the new Standards cannot validate a bound Work Spec,\nupgrade that specification through its owning process before adoption. The\nsame preparation formally rolls back any affected `merge-ready` batch and\nplaces every affected `open` batch under `revalidation-required`; the writer\nverifies but does not create lifecycle\u002Fhold changes. The\ntransaction then preserves that Task state and every batch state\u002Fhold, keeps\nQueue membership\u002Forder fixed, increments the structural `queue_revision`,\nupdates the synchronized Contract\u002FStandards\u002FProfile\u002Fload set, and appends\nrecoverable evidence. Historical receipt bytes remain unchanged.\n\nEvery adoption consumes immediate Queue consistency on staged after bytes.\nChanged predicates select any additional deferred evidence boundaries: a\nbatch-close or Terminal gate reruns only when that boundary is reached and does\nnot block unrelated earlier work. Historical closed transitions continue to\nverify under the identity that produced them; declared invalidated evidence cannot\nbe reused as current evidence under the new predicate. Current-use receipt\ncatalogs exclude every invalidated-evidence receipt ID accumulated by committed\nadoptions.\n\nThe plan and append-only receipts are the Agent interface. Cambium does not\ncreate or consume a persistent Markdown adoption report.\n\n## Start A Governed Task\n\nAfter initial adoption:\n\n```text\nStandards Overview\n  -> Card Index\n  -> R01 Core Bootstrap Card + the task-specific Runtime Card\n  -> selected-profile bindings\n  -> Read Set and kernel source read-back when required\n  -> applicable gates, deterministic checks, and receipts\n```\n\nBegin with the\n[`Standards Overview`](\u003Ckernel\u002FK00 Standards Overview.md>) and\n[`Kernel Runtime Card Index`](\u003Ckernel\u002FCards\u002FCard Index.md>). Load only the\nroute, profile bindings, and source modules required by the current task.\nCombine additional routes only when their Card Index triggers apply; they do\nnot replace the route for the work itself.\n\nFor every task, first inspect the target repository for `.cambium\u002F`. If it\nexists, do not write content or state and do not initialize or overwrite it:\ninspect and reconcile its current task first. If it is absent, only a\nlong-running, resumable, or multi-batch task initializes it; bounded work\ncontinues without creating empty runtime state.\n\n```text\n# Existing runtime state: always inspect before writing.\npython3 Tools\u002Fcheck_queue.py . --resume-status\n\n# No .cambium\u002F exists and persistent state applies: initialize once.\npython3 Tools\u002Finit_state.py . \\\n  --task-id YOUR_TASK \\\n  --objective \"State the concrete outcome this task must achieve\" \\\n  --exclude \"State one explicit out-of-scope boundary\" \\\n  --completion-semantics build \\\n  --scope-version s1 \\\n  --standards-version YOUR_VERSION \\\n  --profile-manifest profiles\u002Fmy-profile\u002Fprofile.md \\\n  --apply\n```\n\nChoose `build` for corpus-building work that closes through\n`completion-candidate`, R08, and Terminal Proof. Choose `maintenance` for an\nR10 budget-envelope run that closes through the maintenance completion gate\nwithout entering `completion-candidate`. The choice is required and frozen in\nthe Task Contract; initialization never guesses it. A bounded single-note task\ndoes not initialize `.cambium\u002F` merely to record this choice.\n\nA reported writer lock may belong to a live writer or an interrupted write.\nDo not delete it until no writer remains and the state files, receipts,\nrevisions\u002Ffingerprint, pending deltas, and any recorded archive move have been\nreconciled. JSONL receipts are append-only; an uncertain receipt append keeps\nthe lock instead of deleting or rewriting evidence. A new task does\nnot reuse an old namespace, even when the old task is complete or cancelled;\nan explicit archive\u002Frollover process must handle that history. Cambium does not\nyet automate rollover.\n\nOnce the current task is known and valid, inventory Required objects into\nCoverage, declare explicit `batch_specs`, compile the Queue, and run\n`check_queue.py` before activating a batch. Simple single-note work does not\nneed an empty Queue merely to satisfy a formality. The initial compile stores\nan immutable origin receipt in Progress; later same-scope replans use a staged\nCoverage proposal, register its approved exact diff, and never require editing\ncanonical Coverage in advance.\n\nLarge-scale construction, migration, or persistent multi-batch corpus work\nalso configures the selected Profile's `Corpus Planning` slot. Maintain its\nrestricted-YAML Global Map, Capability Matrix, and Gap Register through R13,\nthen run `check_corpus_plan.py`. Agents consume its deterministic JSON\nprojection and the separate semantic-acceptance status instead of storing a\ncopied report. A Profile-bound authority records accepted\u002Frejected Capability\ndecisions from restricted YAML with `record_corpus_acceptance.py`; evidence is\nappend-only JSONL. These artifacts supply explicit topology, capability,\npriority, evidence, and gap-handoff inputs. They do not schedule Queue work or\nreplace Coverage.\n\nA simple batch records `work_spec_path: null` and `work_spec_sha256: null`.\nOnly a complex batch creates a restricted-YAML contract directly under\n`.cambium\u002Fwork_specs\u002F` from `Tools\u002Fschemas\u002Fbatch_work_spec.template.yaml`, then\nbinds that exact path and SHA-256 in Coverage `batch_specs` before Queue\ncompilation. The Work Spec carries batch-specific outcome, instructions,\nacceptance conditions, and constraints; Queue order, lifecycle, holds, and\nreceipts remain in the Required Queue.\n\n```text\n# Fill .cambium\u002Fstate\u002Fcoverage_ledger.yaml with the accepted inventory.\npython3 Tools\u002Fcompile_queue.py . --output .cambium\u002Ftmp\u002Fqueue-proposal.yaml\npython3 Tools\u002Fcompile_queue.py . --apply --actor-role integrator \\\n  --expected-queue-revision 1 \\\n  --expected-sha256 SHA_PRINTED_BY_INIT\npython3 Tools\u002Fcheck_queue.py .\npython3 Tools\u002Frender_queue.py .\n```\n\nLifecycle writes are dry runs unless `--apply` is supplied, and an apply also\nrequires the current revision\u002Ffingerprint printed by the state tools. See\n[`Tools\u002FREADME.md`](Tools\u002FREADME.md) for transition commands, exit code 2\nholds, receipts, Amendment registration and execution, interruption recovery,\nand both completion paths.\n\n## License\n\nCambium assigns licenses by path to its maintained, tracked release files:\n\n- Software and implementation materials under [`Tools\u002F`](Tools\u002F) are licensed\n  under the Apache License 2.0.\n- The standards, profile materials, and project documentation under\n  [`kernel\u002F`](kernel\u002F), [`profiles\u002F`](profiles\u002F), this README, and\n  [`ROADMAP.md`](ROADMAP.md) are licensed under CC BY 4.0.\n\nSee [`LICENSE.md`](LICENSE.md) for the authoritative scope,\n[`ATTRIBUTION.md`](ATTRIBUTION.md) for attribution guidance, and\n[`LICENSES\u002F`](LICENSES\u002F) for the complete license texts.\n\nAdopter-generated profiles, vocabularies, receipts, and runtime evidence do\nnot acquire a Cambium license merely because they are stored inside these\ndirectories.\n","Cambium 是一个面向大语言模型（LLM）代理维护的知识语料库的治理标准与参考工具集。它定义了代理如何加载规则、划定工作范围、保障知识所有权、整合来源、管理长期演进变更，并在任务完成前生成可审计的执行证据。核心采用‘领域中立内核+单一选定配置文件’架构，内核（K00–K13）提供跨域规范性规则，配置文件则注入具体领域上下文（如语言、来源、审计绑定等），二者严格解耦且不可削弱内核约束。工具集提供确定性校验、状态写入控制、模式定义及收据生成等能力，不替代RAG引擎或知识库本身。适用于需长期、可信、可追溯地由LLM代理协同维护结构化知识语料的场景，如企业知识中枢、合规文档库、科研知识图谱运维等。",2,"2026-08-07 02:30:03","CREATED_QUERY"]