Vision
When Wiki A links to Wiki B, the reader agent should:
- Read Wiki B fully
- Identify which sections/threads in Wiki B are relevant to Wiki A's topic
- Store that relevance mapping in a DB record (e.g.,
wiki_relevance table: source_wiki, target_wiki, relevant_sections JSONB)
- During Wiki A's composition, only inject those relevant sections — not the whole wiki or a blind truncation
- Only regenerate the relevance index when Wiki B's content changes
This is like reading a book, finding the chapters in another book that are a good reference, but still understanding that each book has its own storyline. The relevance mapping is cached per wiki pair and invalidated on content change.
Current state
M10 implements a simpler stepping stone: truncated content (400 chars) from up to 8 linked wikis injected into the regen prompt. This works but doesn't understand section-level relevance.
Future scope
wiki_relevance table (source_wiki_id, target_wiki_id, relevant_sections JSONB, computed_at, target_content_hash)- Invalidation: when target wiki content hash changes, mark relevance stale
- Agent reads full target wiki, produces section-level relevance assessment
- Composition uses only relevant sections, not full content
Vision
When Wiki A links to Wiki B, the reader agent should:
wiki_relevancetable: source_wiki, target_wiki, relevant_sections JSONB)This is like reading a book, finding the chapters in another book that are a good reference, but still understanding that each book has its own storyline. The relevance mapping is cached per wiki pair and invalidated on content change.
Current state
M10 implements a simpler stepping stone: truncated content (400 chars) from up to 8 linked wikis injected into the regen prompt. This works but doesn't understand section-level relevance.
Future scope
wiki_relevancetable (source_wiki_id, target_wiki_id, relevant_sections JSONB, computed_at, target_content_hash)