Skip to content

SCHEMA_llm wiki memory template

Jump to bottom
Chris Sweet edited this page May 31, 2026 · 3 revisions

type: reference up: "Home_llm-wiki-memory-template"

Wiki Schema — llm-wiki-memory-template

Conventions and workflows for LLM maintenance of this wiki. Based on the llm-wiki pattern.

Purpose

This wiki is a persistent, compounding knowledge base. The LLM writes and maintains all pages. The human curates sources, directs analysis, and asks questions. Knowledge is compiled once and kept current, not re-derived every session.

Source of Truth

Raw sources (immutable, read but never modify):

  • The template repository code at crcresearch/llm-wiki-memory-template
  • PR descriptions, review comments, merged commits
  • The applied-example derived projects

The wiki (LLM-owned, create, update, cross-reference, maintain):

  • All .md files in this directory

Page Format

Every content page should include:

  1. Title: # Page Name as H1
  2. Opening line: One sentence summarizing what this page is about
  3. Body: Tables, prose, code blocks as appropriate. Concise reference style.
  4. Cross-references: See also: line at the bottom with [Display Name](Page-Name) links

Frontmatter

Every page gets standard YAML frontmatter:

---
type: concept | entity | source-summary | synthesis | index | comparison | untyped
up: "[[Parent-Page]]"
tags: [topic-a, topic-b]
---

Required fields:

  • type:: what kind of page this is (use untyped if unsure)
  • up:: parent page in the hierarchy (usually a category page or index)

Optional typed edges (add when the relationship is clear):

  • source:: literature or raw source this page summarizes
  • extends:: concept or page this builds upon
  • supports: / criticizes:: claim or page this provides evidence for or against
  • related:: lateral connection (prefer specific edges above when possible)

Rules:

  • Every page gets frontmatter, no exceptions
  • Use type: untyped rather than skipping frontmatter entirely
  • Cross-references in frontmatter use [[Page-Name]] wikilink format for Obsidian compatibility
  • Cross-references in body text use [Display](Page-Name) format for GitHub wiki compatibility
  • The frontmatter is designed to feed a knowledge graph pipeline for SPARQL queries; see Knowledge-Graph-Pipeline (not yet implemented; the frontmatter conventions are in force regardless, so the data is already in shape for the pipeline when it lands)

Naming Convention

  • Use Title-Case-Hyphenated.md for page files (e.g., Verification-Gate.md)
  • Navigation files are namespaced: index_llm-wiki-memory-template.md, log_llm-wiki-memory-template.md, etc.

Special Files

index_llm-wiki-memory-template.md

  • Catalog of every page with one-line descriptions
  • Organized by category
  • Update on every ingest

log_llm-wiki-memory-template.md

  • Append-only chronological record
  • Format: ## [YYYY-MM-DD] verb | Subject (verbs: ingest, query, lint, update, create)
  • The first bullet of every entry is the - by: attribution line (see Log Entry Attribution)
  • Then 2-5 bullet points describing the operation
  • Append on every operation, and commit each entry on its own (see Log Entry Attribution)

Home.md

Cross-Referencing

  • Use [Display Text](Page-Name) format in body text (GitHub wiki style)
  • Use [[Page-Name]] wikilinks in frontmatter edge fields (Obsidian graph)
  • Every page should have at least 2 inbound and 2 outbound links
  • Link concepts on first mention within a page
  • Bidirectional: if A links to B, B should link back to A

Edges as Interface Operations

A typed edge is not a label that says "these two things are related." It is an interface contract that defines an operation the agent should perform when it traverses the edge. Each edge type has an expected behavior, an expected target type, and a semantic commitment that shapes how downstream retrieval and reasoning should handle it.

Edge What it licenses the agent to do
extends: Inherit semantic context from the parent. Treat the parent's claims as background assumptions for the current page.
supports: Evidence aggregation. When traversing this edge, expect to combine claims; consistency across supporting pages is desirable.
criticizes: Contradiction detection. Expect an unresolved tension that should trigger conflict-resolution logic before combining evidence.
source: Grounding check. The target is an external source; verify that any cited claim traces back to the source.
up: Parent / breadcrumb. Navigate upward in the hierarchy for category context.
related: Fallback, no specific operation contract. Prefer a more specific edge type where one applies.

Practical implications:

  • Different edge types license different retrievals. The KG pipeline (scripts/kg/) is the eventual consumer of these typed edges to build a SPARQL-queryable graph; the typing is what makes structural queries useful. The pipeline itself is not yet implemented: see Knowledge-Graph-Pipeline and Implementation-Status.
  • Edge types have domain and range. extends: points at a concept or theory; source: points at an external resource. Violating the domain/range breaks the operation.
  • Populate edge fields with the most specific type you can justify. Treat related: as a fallback. Over time, related: uses should become rarer as the edge vocabulary fits the work.

Topology vs Content (when to use the KG)

Two distinct retrieval shapes, each suited to a different question:

  • Topology questions: what connects to what. Multi-hop relationships, concept chains, parent/child rollups, hub detection ("which pages cite this finding?"). The intended path is the SPARQL endpoint that scripts/kg/build-graph.sh would expose; that pipeline is not yet implemented (see Knowledge-Graph-Pipeline), so today fall back to grep across frontmatter.
  • Content questions: what does this page actually say. Definitions, prose claims, specific numbers, source quotations. Use a direct file read or grep.

The right pattern: use the KG to discover where to look (which pages connect to the topic), then file tools to read what the chosen pages say. Reserve grep for non-wiki code or for content searches that span many files.

Log Entry Attribution

The wiki is a shared memory across a team. Every log entry records who performed the operation, so provenance is answerable on the page itself and not only through git blame.

The by: field. The first bullet of every log_llm-wiki-memory-template.md entry is an attribution line:

- by: <human> via <agent>
  • <human> is the value of git config user.name in the wiki repo at the time of the operation. Read it; do not invent it. If it does not match the identity that commits the entry, that is a bug to fix, not a value to guess.
  • <agent> is the coding assistant the operation ran under, for example claude-code or cursor.

One commit per log entry. Never bundle multiple log operations into a single commit. Each append to log_llm-wiki-memory-template.md is committed on its own: commit the page and index changes first, then the log entry as its own commit. This keeps git blame on the log file a faithful per-entry record, one entry mapping to one commit and one author.

Two records, one source of truth. The by: field is the human-readable copy; git history is the verifiable record. They should always agree. If they disagree, trust git and correct the field.

Operations

Ingest (new work completed)

When new sources, experiments, or milestones arrive:

  1. Read the source material
  2. Discuss key takeaways with the user
  3. Create new pages or update existing ones (with frontmatter)
  4. Update cross-references on all affected pages
  5. Update index_llm-wiki-memory-template.md
  6. Append to log_llm-wiki-memory-template.md

A single ingest typically touches 5-15 pages.

Query (answering questions)

  1. Read index_llm-wiki-memory-template.md to find relevant pages
  2. Read those pages and synthesize an answer
  3. If the answer is valuable and reusable, offer to file it as a new page

Lint (health check)

Periodically check for:

  • Orphan pages (no inbound links)
  • Dead links (links to non-existent pages)
  • Stale claims (superseded by newer work)
  • Missing pages (concepts mentioned but lacking their own page)
  • Missing cross-references
  • Pages missing frontmatter: add it based on page content (infer type, parent, tags)
  • Pages with type: untyped: review and assign a proper type if now obvious

When to Update

  • Always: After completing significant work (experiments, milestones, key findings)
  • Always: When findings contradict or supersede previous ones
  • Often: When analytical questions produce reusable answers
  • Periodically: Lint pass every few sessions

When NOT to Update

  • Routine debugging or code fixes (git history is enough)
  • Temporary analysis that won't be referenced again
  • Speculative plans that haven't been executed

Git Workflow

After wiki updates:

  1. Stage changed files by name
  2. Commit with descriptive message
  3. Do NOT push unless the user requests it

Evolution

Update this schema as the project's needs change. It's a living document.

Clone this wiki locally