B. Knowledge Curation: Building the Layer That AI Cannot Build for You

Purpose: AI's usefulness scales with the quality of the knowledge layer it operates over. For individual researchers, that layer is built through years of reading, annotating, synthesizing, and discussing. For research groups, the equivalent layer — shared interpretive consensus, documented methodological decisions, institutional memory of why things were done — is almost never built deliberately. It exists as tribal knowledge: scattered in Slack threads, email chains, undocumented conventions, and the heads of people who might leave. This document argues that knowledge curation infrastructure is the highest-leverage, most underinvested component of AI-augmented research — and describes what building it looks like in practice.

The problem that RAG cannot solve

Most AI use in research follows a retrieval-augmented pattern — RAG (A4.conceptual-vocabulary): you give the AI some documents, ask a question, and receive synthesized output. This works well when the answer is in the documents. It fails structurally when the critical context is not documented at all.

Consider what actually governs interpretive decisions in a project like DISSINET:

• Why was a particular coding category defined narrowly rather than broadly?

• What did the team decide about edge cases in the canonical source set — and why?

• Which analytical approaches were considered and rejected, and what ruled them out?

• What do terms in the codebook mean in practice, as distinct from how they are formally defined?

• What is the working hypothesis this season, and how has it evolved since the project began?

None of this is in any document an AI can retrieve. It is in the distributed memory of the team. When a new member joins, they absorb it imperfectly through conversation. When a longtime member leaves, some of it leaves with them. When you ask Claude to help with a methodological decision, it does not know any of it — not because the AI is limited, but because the information does not exist in retrievable form.

This is the tribal knowledge problem. The solution is not a better retrieval system. It is curation: making implicit knowledge explicit, structured, versioned, and findable.

Wikipedia as the model

Before Wikipedia, finding the answer to "why did the dinosaurs go extinct?" required querying multiple sources, synthesizing them manually, and repeating the entire operation next time someone needed the answer. Wikipedia solved this by creating a materialized view over the raw data of the web: a pre-computed synthesis, maintained and versioned, available at low cost to every subsequent query.

Research groups need the equivalent for their own knowledge. Not a document archive — an archive is a pile, not a synthesis. Not a shared drive of PDFs — that is raw data, not a knowledge layer. What is needed is a set of curated, maintained syntheses over the group's interpretive decisions, methodological conventions, and institutional memory.

The competitive consequence is direct: a research group that has built this layer will use AI qualitatively better than one that hasn't. Every AI query runs over better context. Every new member gets real onboarding. Every session accumulates something rather than repeating the same re-derivation. The group compounds; the group without the layer does not.

What the curated knowledge layer looks like

A research group knowledge layer has several components. These are not documents in the usual sense — they are maintained syntheses that are kept current as the project evolves.

1. Interpretive consensus document

A living synthesis of what the team currently believes about the core questions: the working hypotheses, the evidential basis for them, the strongest counterevidence known, the unresolved tensions. Not the full argument — a structured map of where the team stands and why.

This is distinct from a project description or an abstract. It is an honest account of the interpretive state: what is established, what is working, what is contested within the team, what would change the current view.

An AI given this document can engage with the research at the level of interpretation rather than just retrieval. It can surface counterevidence. It can test whether a new source confirms or challenges the current view. It can identify where a new argument fits in the existing structure. Without this document, every AI session begins from scratch.

2. Methodological decision log

A structured record of methodological choices: what was decided, what the alternatives were, what drove the decision, and what the known limitations of the choice are.

This serves three purposes simultaneously: it gives AI sessions the context they need to give methodologically informed advice; it gives new team members the real methodology rather than the formal version in the methods section; and it gives the team itself a record of what was actually decided, which becomes important when methodological choices are contested in review.

The log is not a narrative of the project's development. It is a structured record: decision → alternatives considered → basis for the choice → known limitations. Dated. Attributable.

3. Codebook with interpretive commentary

Most codebooks state definitions. What they do not capture is how those definitions work in practice — the edge cases, the internal debates, the categories that turned out to need a finer distinction, the entries that look similar but are different for a reason that only becomes clear after coding fifty examples.

This commentary is where the actual methodology lives. An AI given a codebook without commentary will apply the formal definitions. An AI given the codebook with interpretive commentary will apply something closer to what the team actually does.

4. Team CLAUDE.md — the AI-facing knowledge layer

The team CLAUDE.md is the direct interface between the group's curated knowledge and its AI tools. It should contain not just project description and conventions but the structured context that makes AI sessions productive: current working hypotheses, known counterevidence, methodological stances, terminology conventions.

The quality of the CLAUDE.md is a direct proxy for the quality of the team's knowledge curation. A shallow CLAUDE.md produces generic AI assistance. A well-maintained CLAUDE.md produces AI that operates as an informed interlocutor rather than a general-purpose assistant.

See A9.markdown-project-memory for the practical architecture of a research project context file.

Curation as a research practice, not overhead

The objection is predictable: curation takes time that should go to research. The response is that curation is research. The act of making interpretive consensus explicit — of writing it down rather than leaving it distributed — forces the team to test whether the consensus is real. Disagreements that were obscured by the assumption of shared understanding become visible. Decisions that were never actually made become visible too.

The teams that find curation most expensive are typically the teams that have the least explicit agreement. The apparent cost is not the cost of documentation — it is the cost of the unresolved disagreements becoming legible.

There is also a compounding return. A well-maintained knowledge layer reduces the overhead of every subsequent session. The researcher who has to reconstruct context before each AI interaction pays the reconstruction cost repeatedly. The researcher whose context is maintained in structured documents pays it once.

The analogy to spaced repetition is exact: the investment in making knowledge durable is paid once; the returns are paid out in every future encounter with the domain.

The provenance problem

One component of knowledge curation that research groups consistently underprioritize is provenance: the ability to trace a claim or interpretation back to its source and the reasoning that generated it.

AI-generated outputs are particularly vulnerable here. When a synthesis, a framing, or a draft argument is produced by AI and then incorporated into the project's working documents, the question of where it came from becomes opaque. The document looks like the team's work. It may not represent the team's actual reasoning — it may represent Claude's best synthesis of the team's prior documents, which is a different thing.

Wikipedia has a solution: every claim has a talk page, every edit has an attribution, the history of the document is versioned and navigable. Research documentation needs the equivalent. Not as a bureaucratic exercise, but as the infrastructure that makes the knowledge layer trustworthy rather than just plausible.

Practically: every significant interpretive decision in the group's documents should be attributable — who proposed it, what the evidence basis was, when it was adopted, whether there was dissent. This is good historical record-keeping. It is also what makes the document useful to AI: a claim with an evidential basis is different from a claim without one, and AI can only treat them differently if the difference is marked.

NotebookLM as a partial solution

Google NotebookLM is the current tool that most directly addresses the knowledge curation gap for researchers. It allows a project to maintain a curated set of sources — papers, documents, notes — and query that set as a maintained corpus rather than a general-purpose knowledge base. The queries are grounded; the responses cite sources within the notebook; the notebook can be updated as the project develops.

NotebookLM is not a full solution — it does not maintain interpretive consensus, it does not have a decision log, and it treats all sources as equally weighted rather than distinguishing between established findings and working hypotheses. But it is the closest current tool to the "materialized view over private data" that the knowledge curation argument calls for.

For DISSINET projects: a NotebookLM notebook containing the codebook, canonical sources, key methodological papers, and current working documents is more useful than any of those sources in isolation — because it allows AI queries to be grounded in the project's specific knowledge layer, not in Claude's general prior.

See tool-notebooklm for setup and workflow details.

What good curation looks like at scale

The transition from individual to small-team is where most knowledge is lost. Researchers who maintain excellent individual curation often have no mechanism for making that curation shared — it stays in their personal notes. The team's actual working knowledge lives in a distributed set of individual knowledge layers that are never integrated.

Related

• A4.conceptual-vocabulary — what RAG is and why it's the default AI-research pattern

• B.team-ai — the third-party problem and disclosure practices in collaborative work; this document is the infrastructure layer that makes that collaboration robust

• B.epistemics — sycophancy, confirmation loops, and the tunnel effect; the knowledge curation layer is the primary structural defence against confirmation loops (you can see when the loop is diverging from documented consensus)

• A9.markdown-project-memory — practical CLAUDE.md architecture; the team knowledge layer and the project context file are the same thing, approached differently

• B.autonomy — skill erosion and the conditions under which AI assistance degrades judgment; curation is the practice that keeps the researcher's own knowledge active rather than outsourced

• B.adoption-spectrum — the five-level adoption model; Level 4–5 adoption is only possible with a maintained knowledge layer; the layer is what makes structural integration viable rather than risky