Evidence Chains and Index First

The chain

flowchart LR
  q["Question"] --> map["Knowledge map and indexes"]
  map --> page["Article section"]
  page -->|source_ref + file and lines| region["Source region at a pinned version"]
  region -->|content digest| check["Verified at write and verify time"]

An answer starts from the knowledge map, lands on an article section, and from there follows a reference to an exact region of a registered source. Each step is checkable: the reference names the source and the lines; the source is pinned; the region's content is fingerprinted.

Sections carry their own evidence

Approved articles are divided into sections. Each written fragment cites at most three source positions, each a source_ref plus a file and line locator. When an article is submitted, the CLI checks that each cited source is authorized for that task, reads the current captured text and computes the region's content digest. Unknown or unauthorized paths and source-version drift are errors, not warnings. There is no separate fact table or claim ledger to maintain — the references are the evidence.

source_ref values are opaque, verified identities. Agents copy them exactly; they are not file-system paths.

Checked again before delivery

context verify re-checks approved pages before close and build: source references for freshness and verbatim match, frontmatter identity, section blocks, assets and the derived structure. Verification errors block close and build. Approved Markdown keeps a stable identity in frontmatter and section metadata, so a page can be revised without losing its history.

Index first, then the original

Agents answering from a knowledge package start from directory indexes and the edge records in the build inventory, read the candidate pages, and cite their headings and passages. When the package does not cover a requested fact, they report the gap instead of guessing. Consumer packages omit section metadata to stay small; a maintainer can map any page back to the Context knowledge workspace through the inventory to see its full evidence.

With Source Graph, the chain reaches the code without a clone: the optional evidence plugin joins section markers, knowledge/structure.yaml and source registrations, so an Agent reading code at a pinned revision also receives the knowledge sections that cite it. The plugin is read-only; it does not verify source contents or modify knowledge.

Visible to readers

On a documentation site, each article ends with a source footer built from its recorded references: repository entries link to the recorded revision and module, and document entries link to their registered URL. Links are never inferred from prose.

证据链与索引优先

证据链

flowchart LR
  q["问题"] --> map["知识地图与索引"]
  map --> page["文章章节"]
  page -->|source_ref + 文件与行号| region["固定版本的来源区域"]
  region -->|内容摘要| check["写入和验证时校验"]

回答从知识地图出发，落到某篇文章的章节，再沿引用到达已登记来源中的确切区域。每一步都可校验：引用写明了来源和行号；来源固定在某个版本；区域内容带有指纹。

章节自带证据

已批准的文章按章节划分。每个写作片段最多引用三个来源位置，每个位置由一个 source_ref 加上文件和行号 locator 组成。提交文章时，CLI 会检查每个被引用的来源是否已授权给该任务，读取当前采集到的文本，并计算该区域的内容摘要。未知或未授权的路径以及来源版本漂移都是错误，而不是警告。无需另外维护事实表或论断台账——引用本身就是证据。

source_ref 的值是不透明的、经过校验的标识。Agent 需原样复制它们；它们不是文件系统路径。

交付前再次检查

context verify 会在 close 和构建之前重新检查已批准的页面：来源引用是否最新、是否逐字匹配，frontmatter 标识、章节块、资源文件以及派生结构。验证错误会阻止 close 和构建。已批准的 Markdown 在 frontmatter 和章节元数据中保持稳定的标识，因此页面可以修订而不丢失历史。

先查索引，再看原文

基于知识包回答问题的 Agent，从目录索引和构建清单中的边记录出发，阅读候选页面，并引用其中的标题和段落。当知识包未覆盖所需事实时，Agent 会报告缺口，而不是猜测。面向使用者的知识包会省略章节元数据以保持精简；维护者可以通过清单把任意页面映射回 Context 知识工作区，查看其完整证据。

借助 Source Graph，这条链无需克隆即可到达代码：可选的证据插件把章节标记、knowledge/structure.yaml 和来源登记关联起来，因此 Agent 在固定版本上阅读代码时，也能拿到引用这段代码的知识章节。该插件是只读的；它不校验来源内容，也不修改知识。

对读者可见

在文档站点上，每篇文章末尾都有一个根据其记录的引用生成的来源页脚：仓库条目链接到记录的版本和模块，文档条目链接到其登记的 URL。链接从不从正文推断。