Skip to main content
Glama
enesjakoruzh
Arin016

context-lattice

by Arin016
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Context Lattice

Context Lattice 是一个独立的、来源可验证的记忆索引，用于 AI 编程代理的对话导出。将 Codex、Cursor、Kiro 或你自己的代理生成的 JSON 或 JSONL 指向它，即可检索到一个紧凑的证据包，而不是把整个历史重新灌入下一个上下文窗口。

原始记录保持不可变。分层摘要是有损的、可随时丢弃的导航索引。每一条结果都指回源文件、JSON 记录和 SHA-256 哈希。

快速开始

无需 API 密钥或外部数据库。支持 Python 3.11+。

cd /path/to/context-lattice
python3 -m pip install -e .

context-lattice init --root ~/exports/coding-sessions/
context-lattice ingest ~/exports/coding-sessions/
context-lattice query "Why did we change the retry policy?"
context-lattice query "What is the latest payment reference?" --json --debug
context-lattice inspect
context-lattice verify
context-lattice doctor

默认情况下，数据库创建在 ~/.context-lattice/memory.db，可通过 --db /path/to/memory.db 覆盖该路径。导入接受单个 .json、单个 .jsonl，或者同时包含两者的目录树。init 会基于同一个数据库和源根目录打印可直接粘贴的 MCP 配置，避免 CLI/服务器配置漂移。

Related MCP server: logbook

作为 MCP 服务器安装

Context Lattice 通过本地 stdio MCP 暴露 memory_search、memory_get、memory_explain、memory_sync 和 memory_status。先配置数据库与显式的源白名单，再把任意支持 MCP 的客户端指向已安装的可执行文件：

{
  "mcpServers": {
    "context-lattice": {
      "command": "context-lattice-mcp",
      "env": {
        "CONTEXT_LATTICE_DB": "/absolute/path/to/memory.db",
        "CONTEXT_LATTICE_ALLOWED_ROOTS": "/absolute/path/to/agent/sessions"
      }
    }
  }
}

多个允许的根目录使用平台路径分隔符（macOS/Linux 上为 :，Windows 上为 ;）。memory_sync 是唯一会变更数据的 MCP 操作。搜索证据被明确标记为不可信，受 token 预算约束，并可溯源到源哈希。参见 docs/MCP.md。

输入适配器

--adapter auto 检查记录的信封结构，目前可识别：

  • codex：包含 session_meta 和 response_item 记录的事件 JSONL；

  • cursor：包含消息、气泡或回合的导出对话；

  • kiro：带元数据头部的角色/内容 JSONL；

  • claude：包含嵌套消息块的 Claude Code 项目 JSONL；

  • canonical：稳定的 Context Lattice v1 格式；

  • generic：常见的角色/内容、说话者/文本以及嵌套消息结构。

提供商格式可能会变化。Codex、Cursor 和 Kiro 适配器有意保持宽容并通过 fixture 测试，但 canonical schema 是保证的集成边界：schemas/conversation-v1.schema.json。最小完整示例见 examples/canonical.json。

{
  "schema": "context-lattice/v1",
  "conversation_id": "release-planning",
  "messages": [
    {
      "role": "user",
      "content": "The deployment region is ap-south-1.",
      "timestamp": "2026-08-20T10:00:00Z",
      "fact_key": "deployment-region",
      "entities": ["ap-south-1"]
    }
  ]
}

没有可识别对话内容的记录会被计为跳过。畸形或解析失败的记录会显示在导入结果中，并存储在导入审计日志中。重复导入同一文件是幂等的。

检索模型

  • SQLite 中不可变、仅追加的原始事件；

  • 原始 JSON，外加文件/记录来源与哈希；

  • 用于精确标识符检索的 FTS5/BM25；

  • 带离线特征哈希基线的倒排稀疏 postings 索引；

  • 固定扇出的时间顺序摘要树；

  • 跨词汇、语义和分层候选的倒数排名融合；

  • 通过可选的 fact_key 值形成的更正链；

  • 分歧触发的搜索扩展与基于置信度的弃权；

  • 显式的证据 token 预算和可检查的检索轨迹。

索引器和检索器都是确定性的，且不会调用 LLM。内置的语义模型基于 feature hashing，因此可移植、可精确复现，但弱于学习型嵌入模型。外部 LLM 可以消费这些证据，但它不会被信任来维护记忆索引。嵌入边界可以在不改变证据契约的前提下替换。

按时间排序的分层结构是一种类似线段树的导航索引。它无法取代语义或词汇查找：它裁剪时间范围，而 FTS5 与稀疏 postings 负责定位术语，FTS5 与稀疏 postings 负责定位的词汇和概念。查询时的点积在 SQLite 内聚合，而树只栈有界根集合和 beam 沿着树下探。参见 docs/ARCHITECTURE.md。

测试与评估

python3 -m unittest discover -s tests -v
python3 -m context_lattice.cli eval --output benchmark-results.json
python3 -m context_lattice.cli golden-eval --output golden-results.json
python3 -m context_lattice.cli demo \
  "What is the current meeting room for team-3?"

确定性的 50 题评估会比较近期 token 窗口、滚动摘要、扁平向量搜索和分层混合检索。answer_accuracy 是证据充分性指标，而不是 LLM 评判分数。参见 benchmark-results.json 和 DESIGN.md。

人工审阅的 golden-v1 套件是 source recall、精确率、排序、过期事实、无依据结果、引用完整性和层次分支召回率的发布门禁。当阈值回退时，它会刻意让命令失败。参见 docs/GOLDEN_EVAL.md。

生产姿态

本地优先的核心具有逐对话原子索引更新、WAL 并发、跨进程维护锁、不可变事件、来源验证、受限的输入与检索、嵌套符号定位安全的 MCP 白名单、schema 兼容性检查、CI 和确定性发布门禁。context-lattice doctor 检查数据库完整性、索引新鲜度、FTS5、权限、SQLite、Python 和 MCP。Provider 格式仍然非官方，且可能变化；canonical v1 schema 才是稳定的集成边界。在将任何对象暴露到本地 stdio 之外之前，请先审阅 SECURITY.md。具体的发布检查列表与当前非目标见 docs/RELEASE_GATES.md。

Available Tools

5 tools
memory_explainC

Search memory and include deterministic routing, fusion, and abstention diagnostics.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
token_budgetNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description ''carries the full burden of disclose behavioral traits. 'Search memory' implies a read-only action, but the description does not explicitly state whether it unmutated or requires permissions, nor does it explain the nature of the diagnostics beyond jargon. The behavioral disclosure is insufficient for a tool with no annotatons.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise, front-loaded sentence with no wasted wording or filler. It could use more depth, but that is a completeness issue rather than a conciseness or structure failure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though there is an output schema, the description does not establish the key context: why anyone would choose this over memory_search, what "deterministic routing, fusion, and abstention" means in practitioner terms, or what behavioral tradeoffs come. For a specialized diagnostics tool with no annotations or clear parameter docs, this definition is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needs to compensate for the three parameters explain. 'Query', 'limit', and 'token_budget' are not mentione, and 'token_budget' especially is not self-explaning. The description does not become more contribution for the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Search memory') and a scope ('include deterministic routing, fusion, and abstention diagnostics'), which makes it distinguishable from sibling memory_search. It is clear enough but does not explicitly name or contrast the sibling tools, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The diagnostics wording implies the tool is for explaining or debugging memory retrieval decisions, but the description never explicitly says when to use this over memory_search, memory_get, or memory_sync, nor does it provide any exclusions or alternatives. Usage guidance is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_getB

Resolve one Context Lattice citation and verify it against its original source file.

ParametersJSON Schema
NameRequiredDescriptionDefault
citationYes
include_rawNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description anues "verify" against its original sourcefile, a non-obvious behavior that says the tool checks correctness and isn't just a raw accessor. It does not state outverification failures, permissions, or side effects, so the behavior is only partially disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted or repeated information. It fronts the main action and adds only the verification detail in the second clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but missing include_raw semantics and the format/form of a citation means the agent cannot safely choose correct arguments. The output schema may explain return but no the input field, and no annotation compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only clarifies that the citation targets a Context Lattice item. It does not describe include_raw, its default, or its effect, so an agent is left to guess how to request the raw variant. This is a significant gap for a two-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific action—resolving a single Context Lattice citation—and an additional verification behavior, which separates this from a plain search or sync operation. It does not fully demes multiple beats "Context Lattice" and "original source file" due to jargon, so no full 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is used when you already have a citation to resolve, rather than when searching or syncing. It never explicitly contrasts with siblings or explains when not to use it; the intended spot in a generate pipeline is inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_statusA

Report corpus, schema, index model, and allowed-source health without message content.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, this description carries the burden of transparency. It explicitly discloses that the tool does not report message content, which is an important behavioral boundary. The verb 'Report' also implies a non-mutating, observability-focused behavior despite no readOnlyHint annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tight sentence with no filler. The key scope ('corpus, schema, index model, and allowed-source health') appears before the clarifying exclusion, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has no parameters and has an output schema, the description provides all needed selection context: what health areas are reported and what is explicitly excluded. There is no missing information that would prevent an agent from invoking it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so no semantic contribution is required from the description. The schema fully covers the empty parameter set, meeting the baseline for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Report') with a specific resource: corpus, schema, index model, and allowed-source health. The added 'without message content' clause disambiguates it from memory_search and memory_get, which would return content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: this is a health/status tool, and the 'without message content' phrasing tells an agent not to use it when message content is needed. It does not explicitly name alternatives or contain a formal when-not-to-use rule, so it is slightly short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_syncB

Incrementally ingest allowed agent-session roots and atomically update affected indexes.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathsNo
adapterNoauto

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral detail. It does disclose 'incrementally ingest' and 'atomically update affected indexes', which is useful, but it doesn't explain side effects, failure behavior, permissions, idempotency, or what 'allowed' means in practice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence with no fluff. The core action 'incrementally ingest and atomically update' is clear and front-loaded, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations, undocumented parameters, and multiple siblings, it is under-specified. It omits usage direction, parameter semantics, and behavior side effects; the output schema helps but doesn't make up for those gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the paths and adapter parameters. It doesn't name either parameter or explain what paths and adapter expect, nor how they affect synchronization.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly specifies a distinct operation: incrementally ingest allowed agent-session roots and atomically update indexes. This distinguishes it from the read-oriented sibling tools memory_search, memory_get, memory_explain, and memory_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to call this tool, when not to call it, or how it relates to memory_search and memory_get. The only contexts is inferred from the phrase 'sync', but the description never says when synchronization should be triggered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.3.0
    • First observedmemory_explain
    • First observedmemory_get
    • First observedmemory_search
    • First observedmemory_status
    • First observedmemory_sync
Deploy Server
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation4/5

The tools are mostly distinct in purpose: search returns evidence, get resolves a specific citation, explain adds diagnostics, sync ingests data, and status reports health. The only meaningful overlap is between memory_search and memory_explain, since both perform searches, but their different outputs make the distinction usable.

Naming Consistency4/5

All tools share the consistent memory_ prefix and lower_snake_case convention. The minor deviation is memory_status, which names a state rather than an action, while the other four tools use memory_ followed by a verb-like operation.

Tool Count5/5

Five tools is a well-scoped number for a memory/context server. Each tool covers a distinct part of the workflow: search, resolution, explanation, sync, and status.

Completeness4/5

The surface covers the core memory lifecycle: retrieval, verification, diagnostics, ingestion, and health monitoring. There is no explicit delete/forget or curation operation, but this is a minor gap because memory appears to be source-backed and managed through the sync tool.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • chat-history-db

    ThinkofRain1213
    F
    license
    Not graded
    quality
    F
    maintenance
    Enables AI coding agents to persistently store and retrieve conversation history with hybrid semantic and keyword search, cross-encoder reranking, session filtering, and archiving through MCP tools.
    -

  • logbook

    olly-styles
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides full-text search and retrieval of archived Claude Code session transcripts, enabling agents to inspect past sessions without loading entire transcripts.
    2
    MIT

  • motif-solo

    motif-Labs
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables coding agents to retrieve a bounded context packet linking relevant code with prior session evidence, decisions, failures, and fixes from local Codex and Claude Code history.
    Apache 2.0

  • Literature Evidence MCP

    phy-zhangzl
    A
    license
    A
    quality
    C
    maintenance
    Enables local-first, versioned evidence retrieval from papers without loading the whole library into a conversation, with optional Zotero, writing, fixed-commit code, and experiment record integration returning bounded excerpts and page images.
    5
    1
    MIT