Knowledge: Extract, Retrieve, Synthesize

From layout-aware extraction to durable, wiki-grounded research memory

Priscila Moreira

Charles Vardeman

James Sweet

Chris Sweet

July 9, 2026

From PDF to structured elements

Stage 1 · Extraction · paper structure, live

This is Priscila’s paper-atomizer explorer running on the Mercadier 2011 uranium-deposits paper. The tree on the left is the DoCO / FaBiO / PROV containment hierarchy — front matter, body matter, back matter, then sections, subsections, paragraphs, figures grouped with their captions in FigureBoxes. Every leaf element carries a page number and a bounding-box region (xywh fragment selector against the page image), so any assertion downstream can be traced back to the exact pixel region on the page.

Point out: the sections and figures aren’t just text. They’re typed nodes with provenance edges to the software agents that produced them — DeepSeek-OCR for layout and bounding boxes, Claude for heading classification, Gemini for figure classification and chart extraction. Every step is recorded as a prov:Activity. This is what “layout-aware extraction” produces before the concept graph on the next slide gets built from it.

The document graph, live

Stage 2 · Ingestion · real output from the extraction pipeline

The extraction pipeline turns a source document into a typed RDF graph: the document at the center, section chunks around it, and the concepts each chunk mentions fanning out. Every concept carries two @type slots — one canonical (SPARQL-queryable across the whole corpus) and one domain-specific (grown from the source, no pre-declaration). The graph on the left is a real slice from a real briefing; the JSON on the right is the actual output.

{
 "@id": "did:doc:a5bf...",
 "@type": "prov:Entity",
 "schema:name": "CLAIMS-BRIEF",
 "schema:hasPart": [{
  "@id": "did:heading:9da2...",
  "@type": [
   "schema:CreativeWork",
   "ex:heading_chunk"],
  "ex:heading": "Design principles",
  "skos:member": [{
   "@id": "concept:late_binding",
   "@type": [
    "skos:Concept",
    "ex:design_principle"],
   "skos:prefLabel":
    "Late binding everywhere"
  }]
 }]
}

Two @type slots: canonical → SPARQL, ex: → corpus-grown.

This is a real graph from the extraction pipeline: a briefing document about claims-based extraction and retrieval, run through the pipeline, output as JSON-LD. Fifteen chunks; five shown here. Each chunk carries its extracted concepts as skos:member edges.

The point to make: every concept has a two-slot @type. The first slot is canonical (skos:Concept) so it’s SPARQL-queryable across the corpus. The second slot is domain-specific (ex:design_principle, ex:trust_tier, etc.) — the ontology accretes from the source without pre-declaration. Fixed ontologies force the corpus into a schema chosen in advance; this keeps the closed-envelope queryability and the open-payload growth in the same node.

Drag a Concept node to inspect it. The interactive graph is doing the same work as three static slides would have.

Two kinds of “hop”

Terminology · reasoning-hops vs retrieval-hops

Multi-hop in the literature conflates two different concepts.

Reasoning hop

A property of the question. One step in an inference chain, fixed by dataset annotation.

MuSiQue’s “2-to-4 hop questions” are compositions of connected single-hop questions, each depending on the previous answer.

Trivedi et al., TACL 2022

Retrieval hop

A property of the system’s execution. One retrieval iteration, or one edge traversed in a graph, at run time.

What our random walk does. Walk length is a retrieval-hop count.

HopRAG · IRCoT

These don’t need to align. Even single-reasoning-hop questions need multiple retrieval hops to build the context envelope (layout, related concepts, cross-document relationships) around each retrieved chunk.

Terminological pre-emption for the “why not just split the questions?” objection.

Say: “There are actually two different notions of ‘hop’ in the RAG literature, and they get mixed constantly. Reasoning-hop is a property of the question, fixed at dataset construction. Retrieval-hop is a property of the system’s execution. MuSiQue’s 2-to-4 hop labels are reasoning-hops. Our random walk operates in retrieval-hop space. These are not the same thing.”

Then the natural follow-up: why don’t retrieval-hops align 1-to-1 with reasoning-hops? Because retrieval also has to assemble the context envelope (layout, related concepts, cross-document relationships) around every chunk. That context isn’t derivable from the question at all. Question decomposition only touches the question; the graph walk brings in structural and relational context that no amount of splitting reaches.

Strongest version if pressed: the walk’s stationary distribution is computed offline, before any question comes in. It’s a property of the corpus, not the query. The question only enters at query time to derive our ranking. If retrieval-hops were reasoning-hops, the walk would need the question at every step. It doesn’t.

Transition to next slide: the 4-hop bridge chunk buried at rank 1,800 on the next slide is a retrieval-hop failure, not a reasoning failure.

Dense RAG breaks on the bridges.

The retrieval problem

Dense RAG: embed the question, cosine against chunk embeddings, take top-K, hand to the LLM. One-shot similarity.

• Works for hop 1 — the passage that lexically matches the question.
• Breaks on multi-hop — bridge and answer chunks share no vocabulary with the question.
• Breaks at scale — with a real corpus of distractors, similar-but-wrong passages drown the true evidence.

Multi-hop retrieval is a graph traversal problem in disguise.

Measured · 21,100-chunk corpus · MuSiQue TEST

Rank 1

The direct-match gold chunk. Stays at rank 1 at any corpus size.

~1,800

The 4-hop bridge chunk. Median rank of 21,100.

22%

all-gold@30 · vs 88% on a small distractor-free set.

Dense retrieval is a hop-1 tool. Multi-hop needs structure, not more similarity.

The failure is measured, not asserted. On the full 21k-chunk corpus, the first (directly-matched) gold chunk stays at rank 1 at any corpus size — cosine finds what it can find. The deepest 4-hop bridge chunk sinks to median rank ~1,800. all-gold@30 collapses from 88% (small clean set) to 22% (full corpus). Dense RAG solves hop 1 and collapses on the bridges. The rest of this section shows what structure buys you.

Markov chain: retrieval as a random walk

Live simulation · markov_embeddings_and_rag

The simulation running on this slide is from the markov_embeddings_and_rag project, dropped in as an iframe. Same trick as the Cytoscape graph on the later slide, different underlying library (vis-network). The point of showing it here is not the mathematics; it’s that a live simulation the group actually developed as part of their research is on the slide, driveable by keyboard, no Alt-Tab.

Talk track: press Play, let the walk propagate for a few seconds, mention that the top-5 nodes list on the left is the RWR steady state converging, and that this is exactly the mechanism the “Random-Walk-With-Restart” concept in the KG graph (later slide) refers to.

The missing layer: durable synthesis

Transition · from retrieval to memory

Extraction gives you records. Analysis gives you answers. Neither gives you memory — knowledge that compounds across sessions and researchers.

Today that understanding lives in someone’s head, in stale notebooks, in README fragments. It walks out when the person leaves.

Where knowledge accumulates today

• Presentation · papers, reports
• Synthesis · [ MISSING ]
• Analysis · notebooks, dashboards
• Storage · PostgreSQL, PubMed, WoS

What a synthesis layer needs

• Persistent · Markdown in git, grows monotonically
• Human + agent readable · one substrate, no lock-in
• Cited & traceable · every claim links to source
• Queryable as a graph · typed edges → SPARQL KG

llm-wiki-memory-template fills this layer. The rest of the talk is what that looks like in practice.

This is the transition slide from the retrieval work to the wiki work. The framing is straight from the synthesis-layer story: extraction is stage 1, analysis is stage 2, and there’s a gap between analysis and presentation where “the group’s understanding” is supposed to live. Today it lives in whoever’s head is closest to the work. The rest of the talk is about the pattern that fills that gap.

Two ways in

The template’s two ingestion modes

Direct-ingest · schema-extraction into wiki pages

For a group’s own papers, a thesis lit review, a research-execution wiki.

Each source becomes a typed page (SourceSummary, LiteratureNote, MethodNote) with frontmatter edges (extends, supports, criticizes, up).

The KG is over pages — categorically different from the per-document parse graph on slides 2-3.

markov_embeddings_and_rag, AI-Sci-Disc-Mem, SavoieAgentKnowledge, web_forager — all direct-ingest.

Synthesis over a pipeline · above the document-parse graph

For large corpora where you first run extraction + retrieval — slides 2-5’s paper-explorer, document graph, 21,000-chunk MuSiQue.

The pipeline document-parses; the wiki sits above it, capturing what survived cross-checking and what was walked back.

earth616 — synthesis on top of the extraction pipeline.

Same substrate, same discipline gates, same SPARQL queries — categorically different graph. The rest of the talk shows the direct-ingest mode.

Important framing point: llm-wiki-memory-template is not just a synthesis layer that sits above a large extraction pipeline. It’s the memory substrate, and it has two natural entry points.

The two modes produce categorically different graphs, not scaled versions of the same thing. Priscila is developing this distinction as an explicit taxonomy on the crcresearch/data-extraction-wiki-memory wiki (see the Schema-Extraction-vs-Document-Parsing page): schema-driven extraction fills predefined structure (like the SourceSummary/MethodNote/LiteratureNote page types in a wiki), while document parsing reconstructs the whole page (layout, reading order, tables, figures — what the paper-explorer on slide 2 shows). Different tasks, different training, different outputs. Confusing the two is the most common source of wasted implementation effort in extraction work.

Direct-ingest is what most academic work actually needs. You have your group’s own papers (or your thesis’s cited literature, or your course’s reading list) — dozens to hundreds of sources, not millions of chunks. Each paper deserves its own wiki page with frontmatter that says what it argues, what it extends, what it criticizes. The KG that builds is a semantic graph OVER pages, not per-document extractions. That’s what AI-Sci-Disc-Mem does (115 papers × 20 topics). That’s what SavoieAgentKnowledge does (91 papers × 7 research problems). That’s what the web_forager case study you’ll see next uses.

Synthesis-over-a-pipeline is what you do at extraction scale. When you’re running MuSiQue at 21,000 chunks, the wiki isn’t ingesting the raw chunks — it’s synthesizing what the pipeline learned. Which experiments survived, which drifted, which were walked back. That’s what markov_embeddings_and_rag does.

Same template. Same discipline gates. Same SPARQL substrate. Different starting point. The rest of the talk mostly shows direct-ingest, because that’s what will resonate with most of the audience — but the same wiki works for both.

Every LLM session starts from zero.

The problem

Session 1context re-pasted

∅nothing
carries over

Session 2context re-pasted

∅nothing
carries over

Session 3context re-pasted

• ChatGPT and Claude conversations do not remember the last one.
• Retrieval over your group’s PDFs rediscovers the same chunks on every query.
• Nothing accumulates between conversations. Nothing compounds between collaborators.

When the student who ran the analysis graduates, so does the knowledge.

Failure paths, preserved not deleted.

Memory that compounds · the file-drawer effect, Rosenthal 1979

Journals publish the win.

The abandoned method, the walked-back claim, the metric bug that inflated an earlier result — all deleted from the record.

Every group has a student who repeated a failed method because no one told them.

The wiki keeps the trajectory.

When an approach turns out wrong, the corrected successor is filed alongside the original with a cross-reference back; the failure stays in place with a Status note pointing forward.

A verification gate ensures new claims land alongside the ones they qualify, not on top of them.

A reader arriving a year later encounters the trajectory, not just the answer.

The file-drawer effect (Rosenthal 1979) is the canonical failure mode of scientific record-keeping: only positive results get written up, the abandoned methods and walked-back claims never enter the literature. The wiki-grounded pattern is append-only by convention (Saboia Moreira et al., 2026). Corrected pages are filed alongside originals, not on top of them. A verification gate enforces this at commit time. The reader gets the trajectory, not just the answer — which is what makes the pattern durable across student generations.

Case study: the two-author demo branch

Real world example · Web Forager

Chris Frederick pushed a demo branch (commit 81e03e2) for a customer preview and filed the results in a wiki page — Experiment-11-Productionization. The frontmatter carried an extends: edge that would matter later.

---
type: synthesis
up: "[[Experiment-10-Vocabulary-Alignment]]"
related: "[[Experiment-8-Second-Entity]]"
extends: "[[Experiment-7-Question-Deepen]]"
supports: "[[Working-Hypothesis]]"
---

Frontmatter on Experiment-11-Productionization. The extends: edge inherits the analytic frame from Experiment 7.

Reported numbers · Sonnet · 3-entity gold set

Entity	Reported
ITAMCO	17 / 17
Southwire	14 / 17
CRC-ND	17 / 17

Ship it?

Chris Sweet opens a separate Claude Code session on main to sanity-check. Two agents, one wiki carrying the state between them.

Setup for the case study. Two-author project: Chris Sweet plus a colleague (Chris Frederick / Omegaice on GitHub) on a Web Forager web-scraping tool. The reported 17/17 entity coverage for the flagship customer is the claim under review. The reviewer is not the person who ran the pipeline — they’re picking it up cold from the wiki. That framing matters: this is the “the wiki has to carry the load” scenario, not “the person who did the work is standing next to you.”

Next slide (Slide 8): the finding — the reviewer walked the wiki’s typed edges backward, saw a hedge-counting bug, real coverage was 8/17.

The reviewer walked the wiki, not the code.

Case study · the finding

Experiment 11

↓ extends:

Experiment 7

↓ extends:

Experiment 8

Same inherited setup across all three.

Following the extends: chain, the reviewer surfaced the mechanism: the pipeline treated the model’s honest “not visible on this page” answer as a successful extraction and stopped the search — exactly the case where deeper searching was warranted.

Reported vs. evidence-based counts

Entity	Reported	Real
ITAMCO	17 / 17	8 / 17
Southwire	14 / 17	6 / 17
CRC-ND	17 / 17	4 / 17

The bug cascaded across Experiments 7, 8, and 11. The graph, not a debugger, told the reviewer where the fix had to reach.

The LLM refusing to hallucinate looked identical to the LLM answering. The search stopped in exactly the case where deeper searching was warranted.

The specific mechanism to name: the frontmatter extends: edge on Experiment 11 pointed to Experiment 7. Experiment 7 pointed to Experiment 8. Following those typed edges backward surfaced the fact that the same inherited analytic frame was in all three experiments — so the bug was too.

The bug itself: the pipeline had a check that treated the model’s hedge (“not visible on this page”) as a positive extraction. Every time the LLM was being honest about not seeing an entity, the pipeline was recording that as a successful answer AND stopping the search — meaning it never went to the next page where the entity might actually be visible.

Real coverage on the flagship customer was 8 of 17, not 17 of 17. And the fix had to cascade: not just Experiment 11 (where the finding surfaced), but back through 7 and 8 too. The typed-edge chain told the reviewer where the cascade needed to reach.

What made this possible

Case study · what worked

Two authors, two sessions, no coordination.

Both in Claude Code, no handoff meeting — the wiki carried the state.

The typed extends: edge is what made the cascade legible.

Body links would have said “these are related somehow.” The typed edge said “this experiment inherits its analytic frame from that one; if that is wrong, this one probably is too.”

75% coverage recovery after the fix cascaded back through two prior experiments.

Extends chain plus the two criticism edges. Same shape as the demo-branch cascade the reviewer walked.

Full case study: la3d.github.io/WGRA/wiki-collaboration-story/

This does not happen with RAG. Similarity search cannot walk semantic edges backward across experiments.

Three claims worth landing before moving on:

1. Two-author collaboration mechanism worked. No coordination overhead — each author was in their own Claude Code session on their own branch, and the wiki was the connective tissue. That is what “team scale” looks like in practice.

2. The typed edge was load-bearing. A body hyperlink would have said “there’s a connection somewhere.” The typed extends: edge said “this page inherits its analytic frame from that one; if the parent is wrong, this one probably is too.” That semantic content is what let the reviewer’s agent walk the cascade.

3. 75% coverage recovery is a real number on the flagship entity. The fix cascaded backward through 2 prior experiments; each got a commit and a page update. The wiki preserved the trajectory — original error still findable, correction filed alongside — exactly as failure-path preservation is designed to work.

Contrast with RAG: similarity search can retrieve similar chunks. It cannot walk semantic edges backward. That’s the argument for typed structure over embedding-only retrieval.

Team scale · collaborative within a group

The wiki carries the trail across collaborators

Lab notebooks. Slack. Google Docs. Jupyter notebooks. Half-remembered meeting slides. Protocol binders. Thesis drafts.

A postdoc and a grad student on the same project keep notes across all of these in parallel silos. When the PI checks in a month later, most of the trail is scattered or lost.

One attributed wiki instead.

Every log entry carries a by: <human> via <agent> line. Git preserves the amendment history. Concurrent writes: mechanical conflicts resolve automatically; semantic ones route through an LLM-assisted merge.

## [2026-06-30] ingest | Claims-Plus-Walk proposal
- by: Chris Sweet via claude-code
- Created synthesis page [Claims-Plus-Walk]:
  make the atomic claim the retrieval unit for
  MuSiQue; the random walk over a claim graph is
  the mechanism, and entity resolution becomes an
  output of trajectory completion.
- Cross-linked bidirectionally from
  [Bridge-Entity], [Markov-Chain-v5c2],
  [Operations-Basis].
- Testable predictions filed: claim granularity
  gives cleaner trajectory edges than v5c2 (H1);
  claims-plus-walk degrades less on the 281→21k
  jump (H2); ...

Real log entry from the markov_embeddings_and_rag wiki. by: + via: become the audit trail — verifiable in git via git blame on the log file, no separate metadata store, no vendor system.

The Web Forager case study demonstrated this in practice: two authors, two Claude Code sessions, no synchronous coordination. The wiki was the connective tissue between the two branches. Every log entry had by: <human> via <agent> attribution, so the reviewer could trace who claimed what without asking the person.

Mechanically: the wiki-write-protocol handles concurrent writes through git’s optimistic-push with retry, plus .gitattributes merge=union for append-only files. When there’s a semantic conflict (two people editing the same page’s frontmatter), an llm_resolve skill routes the merge through the LLM. Both edits land with correct attribution.

Team scale · federated across groups

Each group publishes an agent card. Peers discover you by grepping topics.

Comp-chem overlaps with materials science, biophysics, catalysis.

Every group is quietly re-answering questions another campus group already answered last year. When a PI leaves, that group’s institutional memory walks with them.

Each group runs its own wiki, its own permissions. The agent card is how peers find you: grep the topics, discover the capabilities, DM the mailbox.

Three federation modes:

• ask — clone-and-invoke, synchronous. Shipped in v0.1.0.
• message — async DMs to a peer’s inbox. Designed, not yet published.
• post — channel broadcasts to subscribers. Designed, not yet published.

---
type: agent
id: chrissweet/model_fusion
description: Fusion models for pharmaceutical
  discrimination using NIR + PAD imagery.
capabilities:
  - train-cnn-pad-classifier
  - train-pls-r-nir-regressor
  - design-fusion-strategy
topics: [pad-cards, drug-quantitation,
         cnn-classification, nir-spectroscopy]
endpoints:
  inbox: mailbox://chrissweet/model_fusion
---

Agent card from the model_fusion group. The capabilities: and topics: fields are what peers grep against when they need help.

See MVP Eval Run 1 on the team-scale page of the flyer — a five-minute clone-and-invoke federation session across three agents on a real PAD classification task.

Agent capability · built-in workflow

Discipline in the artifact, not in the head of whoever prompts best

Raw group subscription: every student prompts differently. The discipline lives in memory. It walks out with them.

Configured environment: the discipline is in the repo. Every session starts from a known baseline. Any agent that reads .claude/skills/ gets it.

• Four operations as single commands: wiki-source, wiki-experiment, wiki-lint, plus the verification gate at commit time.
• SessionStart hook injects the wiki index + last 5 log entries at every session boot. Agent starts oriented, not blank.
• Discipline gates catch common rationalizations before commit — e.g. “I’ll add the corpus tag later” becomes a warning right when it appears.

---
name: wiki-source
description: Ingest a new source document (paper,
  article, design doc, README, external reference)
  into the wiki. Creates a source-summary page
  and links it into the existing wiki neighborhood.
---

# Procedure (condensed)
1. Read the source; discuss takeaways with user.
2. Create source-summary page. Frontmatter:
   type: source-summary,
   up: closest existing parent page,
   source: URL or filesystem path,
   typed edges (supports:, criticizes:,
   extends:) to related wiki pages.
3. Body: one-sentence opening; sections for
   contribution, methods, intersections, quotes.
4. Update related pages; fix cross-refs in
   both directions on every affected page.
5. Update index; append log entry with
   by: <name> via claude-code.
6. Run Verification Gate at commit time.

The real wiki-source skill file from the template (condensed). Every project instantiated from crcresearch/llm-wiki-memory-template gets the same procedure, model-agnostic.

Say: “The workflow isn’t a Slack channel where senior people remind juniors of best practices. It ships as skill files in the repo. Every session, the SessionStart hook injects the wiki index and the last five log entries, so the agent starts oriented instead of starting blank. The verification gate then fires at commit time — you can’t file a claim like ‘73.3% on MuSiQue’ unless the wiki page traces to real script output. Projection-as-fact detection at the artifact level, not at the reviewer’s discretion.”

The four operations that ship as single commands, all in the base template: wiki-source (ingest a paper/article/design doc into a source-summary page; the RHS on this slide shows a condensed version of the actual skill file), wiki-experiment (file experiment results), wiki-lint (health-check the wiki for orphan pages, dead links, stale claims), and the verification gate (fires as a PostToolUse advisory hook). All four are in the .claude/skills/ directory of crcresearch/llm-wiki-memory-template.

Agent capability · multi-AI model

Model-agnostic by design

Vendor-locked AI: the memory lives with the vendor. Their subscription changes, your workflow breaks.

Wiki-grounded: the memory is yours in git. Swap the AI.

Different agents read the wiki through their own overlay directory:

• wiki/agents/claude-code/ — slash commands, hooks
• wiki/agents/cursor/ — .mdc rules
• wiki/agents/opencode/ — coming
• (Add your own — the pattern is documented)

Same wiki, same schema, same discipline gates. The by: <human> via <agent> line captures which tool did which write.

## [2026-06-14] ingest | Schema extension
- by: Chris Sweet via claude-code

## [2026-06-25] sync | Test harness rename
- by: Chris Sweet via claude-code

## [2026-06-30] ingest | Claims-Plus-Walk
- by: Chris Sweet via claude-code

## [2026-07-04] update | Cursor overlay wired
- by: Chris Sweet via cursor

## [2026-07-05] ingest | New paper section
- by: Priscila Moreira via claude-code

The audit trail records which tool wrote what. When a new model appears, adopting it is a new overlay, not a migration.

The multi-AI story is really about durability. The AI vendor landscape churns every six months — a group Claude subscription might be a Cursor + Copilot subscription next semester and something else after that. If your workflow is locked to a specific vendor, you migrate every six months. If your workflow is a wiki plus a set of skill files, adopting a new agent is writing an overlay, not a migration. Same wiki, same policy files, same discipline gates. The via: <agent> field on every log entry is what makes it auditable which tool did which write.

Federation is the multi-wiki story. Each group is autonomous — its own wiki, its own permissions, its own git remote. The interoperation layer is an “agent card” (published by each wiki) that describes what the group knows about and how to reach it.

Your agent can then issue a query to a peer group’s wiki. Practical example: your colleague in comp-chem answered a DFT-functional-benchmarks question last year and filed it in their wiki. You don’t have to email them — your agent asks their agent, gets a cited response back with links to specific pages in their wiki, and files the answer in yours with the attribution preserved.

The ask mechanism (clone-and-invoke claude -p in the peer wiki) is in template v0.1.0. The message/post mailbox skill is not yet published; it’s a maintainer-machine-only artifact today.

One ontology, every wiki: the semantic foundation

Shared substrate · llm-wiki-colab

28 classes, four groups.

• Core concept · Concept, Entity, Tool
• Note types · Literature, Method, Theory, Implementation, …
• Structure pages · Index, MOC, Decision, Finding, …
• Person / Org

36 semantic properties connect them: extends, supports, criticizes, related, up, authorOf, defines, source, …

The ontology ships at la3d.github.io/llm-wiki-colab. Every wiki instantiated from the template inherits it — no per-project schema work.

SHACL shapes validate structure at commit time. Eleven canned SPARQL queries (hub-notes, ancestors-of, supports-criticizes, …) ship in scripts/kg/sparql/.

Next slide: this ontology applied to a real research wiki — 51 pages, 1,162 triples, live.

Wiki-page frontmatter uses typed edges — extends:, supports:, criticizes:, related:, up:. The KG-build pipeline (scripts/kg/build-graph.sh) walks the wiki, reads each page’s frontmatter, and emits an RDF triple per typed edge. The result is a real semantic graph — 28-class ontology from the shared llm-wiki-colab project, SHACL-validated, queryable with SPARQL.

The template ships eleven canned SPARQL queries: hub-notes (this slide), ancestors-of (transitive up traversal), supports-criticizes (evidence edges), orphan-notes (unlinked pages), and others. Each is executed in-process via rdflib against the built graph-full.ttl. Deep dive: la3d.github.io/WGRA/knowledge-graph/.

The same ontology, a real research wiki

Live instance graph · markov_embeddings_and_rag

markov_embeddings_and_rag

30 nodes, 39 edges. Real research wiki, reified to RDF.

Gold-highlighted edges are the same shape as the web_forager cascade:

• 4-hop extends chain
• 2 criticizes edges

Random-Walk-With-Restart — central hub, 48 inbound edges. Surfaced by hub-notes SPARQL, not authored.

No Alt-Tab. Drag nodes to interact.

Say: “This is a different research wiki, same pattern. The gold-highlighted edges have the exact shape as the web_forager cascade I just described — a four-hop extends chain from a leaf finding back through experimental lineage to a foundational concept, and a criticizes edge from that same leaf finding to a page five hops up its own ancestry.”

Then drag a node to demonstrate interactivity. Zoom in on the gold cluster.

Advantage over the PowerPoint version: no Alt-Tab to Safari, no browser-tab risk, no fallback screenshots. If Wi-Fi drops during the talk, this slide still works because everything is local.

The pattern across three project types

Same template, three genres of wiki

Web Forager Research execution

Two-author project, typed-edge cascade caught a hedge-counting bug before shipping.

8 of 17 → 17 of 17. 75% coverage recovery.

(the case study you just walked through)

AI-Sci-Disc-Mem External literature survey

115 papers under 20 topic Indexes, 453 typed cross-references.

Chemistry ↔︎ Foundation Models: 18 (the dominant interdisciplinary bond, surfaced by graph query).

The graph shows what actually connects to what.

SavoieAgentKnowledge Group publications catalog

91 papers × 7 research problems. Two dominant problems capture half the work; YARP surfaces as the internal method landmark.

31% of papers still unassigned — the graph knows its own backlog.

Same template, same ontology, same discipline gates. The wiki content is domain-specific.

Three concrete instances of the same pattern. Web Forager (which we just went through) is a research-execution wiki with typed evidence edges — the extends cascade caught a specific quantitative bug. AI-Sci-Disc-Mem is a literature survey, 20 topics with cross-references — the graph tells the maintainer which sub-domains actually talk to each other. SavoieAgentKnowledge is a group’s own publications catalog — 91 papers under 7 research problems, with 28 papers still awaiting triage. Three genres, one template, one discipline pattern.

Getting started: fifteen minutes to a working wiki

Adoption

What ships in v0.1.0

• crcresearch/llm-wiki-memory-template on GitHub
• .claude/skills/ — wiki-source, wiki-experiment, wiki-lint
• scripts/kg/ — build-graph.sh, SHACL shapes, 11 SPARQL queries
• Verification gate + discipline gates preconfigured
• ask federation mechanism
• Cursor overlay + minimal-agent mode

Same template as microelectronics-tutor-demo, model_fusion, agent-comms, and the case studies you saw.

Five steps to a working wiki:

1. Use this template on GitHub, clone locally.
2. ./scripts/instantiate.sh "My Project"
3. Ingest your first source — paper, dataset, code repo.
4. Ask a question. The agent files the answer as a wiki page.
5. Commit. Every future session starts from that memory.

CRC helps with initial ingest. Bring your first three papers and we’ll walk through the pattern with you.

The wiki is the project. The AI is a tool that reads and writes it.

Fifteen-minute quickstart. Clone the template, rename, ingest, ask, commit. After the first session, the wiki has your project in it. If someone wants help with initial ingest — especially for domain sources that need a schema-driven connector (databases, complex figures) — that’s what CRC is here for. Bring your first three papers.

Template repo URL: github.com/crcresearch/llm-wiki-memory-template. The README.md there was updated last week to link the Beyond Memory paper and the WGRA flyer up top.

Learn more · Thanks · Questions

Learn more

• Paper Beyond Memory (Saboia Moreira et al., 2026)

• Template github.com/crcresearch/llm-wiki-memory-template

• Semantic foundation la3d.github.io/llm-wiki-colab

• Flyer + deep dives la3d.github.io/WGRA

• Case study (Web Forager) .../wiki-collaboration-story

Contact

Chris Sweet · csweet1@nd.edu Center for Research Computing · Notre Dame

Co-authors

Priscila Moreira · Charles Vardeman · James Sweet

Acknowledgements

Chris Frederick (Web Forager collaborator) · CRC leadership · early adopters (markov_embeddings_and_rag, AI-Sci-Disc-Mem, SavoieAgentKnowledge, Web Forager teams)

Questions?

All the URLs are on this slide. Zenodo concept DOI on the paper — it resolves to the latest version. Template repo is on GitHub. Semantic foundation is llm-wiki-colab. The flyer at la3d.github.io/WGRA has the three deep-dives (memory-that-compounds, team-scale, agent-capability), the KG deep-dive with live SPARQL, and the case-study writeup.

Slack me for the setup session. Bring your first three papers.

Thank you.