What you're trying to do
When I'm working with a vouch KB that has entities, relations, and linked claims/pages, I want retrieval to follow the graph — not just text similarity — because related knowledge often lives one hop away from a search hit.
Example: An agent runs vouch context "auth service". Search returns a claim about JWT, but misses:
- the entity auth-service linked via references
- a depends_on decision on the same subsystem
- the page that includes_claim for that fact
Today, kb.search and kb.context are mostly FTS/embedding driven. Relations exist (and lifecycle ops like supersede/contradict even write relation edges “for graph-traversal queries”), but nothing actually walks them at retrieval time.
I want to ask “what’s connected to this artifact?” and optionally pull those neighbors into context packs after search.
What you've tried
- kb.list_relations(node_id) — lists edges touching a node, but no traversal, no summaries, and not integrated into context assembly.
- kb.read_{claim,entity,page} — manual follow-up after each search hit; doesn’t scale for agents.
- vouch supersede / vouch contradict — create graph edges, but agents still only see them if text search happens to surface the linked claim.
- Obsidian vault sync — graph view in Obsidian, but that’s outside the MCP/JSONL retrieval path agents use.
Suggested shape
New read method + CLI:
-
kb.neighbors / vouch neighbors <node_id>
-
Params: depth (default 1), optional rel_types filter, max_nodes
-
Returns reachable nodes (claim/page/entity/source) plus traversed edges
-
Walks Relation artifacts and structural links (claim→entity, page→claim, supersede/contradict)
-
Excludes retracted claims (archived, superseded, redacted)
-
Context expansion:
-
kb.context / vouch context gains expand_graph (flag)
-
Optional: graph_depth, graph_limit, graph_rel_types
-
After search hits, add 1-hop (or deeper) neighbors with backend: "graph" and lower score than parent hits
-
Emit a warning like graph expansion added N neighbor(s)
Compatibility considerations
Alternatives
What you're trying to do
When I'm working with a vouch KB that has entities, relations, and linked claims/pages, I want retrieval to follow the graph — not just text similarity — because related knowledge often lives one hop away from a search hit.
Example: An agent runs vouch context "auth service". Search returns a claim about JWT, but misses:
Today, kb.search and kb.context are mostly FTS/embedding driven. Relations exist (and lifecycle ops like supersede/contradict even write relation edges “for graph-traversal queries”), but nothing actually walks them at retrieval time.
I want to ask “what’s connected to this artifact?” and optionally pull those neighbors into context packs after search.
What you've tried
Suggested shape
New read method + CLI:
kb.neighbors / vouch neighbors <node_id>
Params: depth (default 1), optional rel_types filter, max_nodes
Returns reachable nodes (claim/page/entity/source) plus traversed edges
Walks Relation artifacts and structural links (claim→entity, page→claim, supersede/contradict)
Excludes retracted claims (archived, superseded, redacted)
Context expansion:
kb.context / vouch context gains expand_graph (flag)
Optional: graph_depth, graph_limit, graph_rel_types
After search hits, add 1-hop (or deeper) neighbors with backend: "graph" and lower score than parent hits
Emit a warning like graph expansion added N neighbor(s)
Compatibility considerations
Alternatives