Build a Research-Repository RAG with Citations

Workflow area: Discovery & Research · Tier: Core · Hands-on time: ~40 minutes

Research repositories fail the same way everywhere: write-only. The reports get filed, the knowledge decays, and six months later someone re-runs a study the team already did. Retrieval-augmented Q&A fixes the access problem — but a naive setup creates a worse one: an oracle that answers every question fluently, blending a 2022 finding with a 2025 one, never admitting when the repository simply doesn't know. The three disciplines that make it trustworthy are citations on every claim, dates on every source, and a hard rule that "we haven't researched this" is a valid — and valuable — answer.

When to use — and when not to

• Use it once your repo passes ~20 documentsbelow that, you can grep and skim; above it, retrieval starts beating memory every time.
• Use it at the start of every discovery cycle"what do we already know about onboarding friction?" before commissioning new research is the single highest-ROI query pattern.
• Use it to arm debates with evidencewhen a stakeholder asserts what users want, a cited answer from actual research changes the conversation's register.
• Skip it as a substitute for new researchthe RAG retrieves what was learned then; users, market, and product have all moved. A 2023 finding about pricing sensitivity is a hypothesis today, not a fact.
• Skip ungoverned setupsa repo Q&A layer that anyone can query but nobody curates fills with stale contradictions and answers them all with equal confidence.

The recipe

1. 1.

   Curate before you index. Inventory the corpus: interview notes (pb-01's reviewed extractions, not raw transcripts), synthesis docs, usability reports, survey readouts, win-loss notes. Exclude drafts, duplicates, and anything superseded. Ensure every document carries a date, a method (interview / survey / usability / support-mining), and a participant-count in its header — the metadata is what makes recency weighting and confidence possible. Garbage in is not hypothetical here; it's the default.

2. 2.

   Load the corpus into your Q&A layer. NotebookLM (free, fast, citations built in): create a notebook, upload the documents as sources. Claude Projects: add the corpus to project knowledge. Dovetail: its magic search runs over your tagged highlights natively. For a first version, NotebookLM's source-grounded answers are the shortest path.

3. 3.

   Install the answering contract. In Claude Projects, put this in the project instructions; in NotebookLM, prepend it to your queries:

   Copy

   You answer questions ONLY from the research documents provided.
   Rules:
   1. Every claim cites its source document and the document's date.
   2. Weight recent evidence over old. When findings conflict across
      time, show BOTH with dates — never silently average them.
   3. State the evidence strength: how many participants/documents
      support the answer.
   4. If the corpus contains fewer than 2 independent sources on the
      question, answer: "Thin evidence" — say what little exists,
      and what research would close the gap.
   5. Never supplement from general knowledge. If it's not in the
      corpus, it's not in the answer.
   

4. 4.

   Calibrate with ten test questions. Five you know the corpus answers — check the citations point to the right documents and the dates are honest. Three you know it cannot answer — confirm you get the refusal, not fluent improvisation; this is the test most setups fail. Two where you know findings conflict — confirm both sides surface with dates. A healthy thin-evidence answer:

   Copy

   Q: What do we know about willingness to pay for the mobile app?
   A: Thin evidence. One source: 2024-11 pricing survey (n=42,
   self-selected) found 31% "would pay" for mobile access — stated
   intent, not behavior. No interview evidence. Gap: no research
   since the mobile redesign shipped. Suggest: 5 customer interviews
   + a painted-door test (see pb-25/pb-26).
   

   If any test fails, tighten the contract or fix the corpus metadata before inviting anyone else in.

5. 5.

   Open it to the team with usage rules. Announce it with three rules: answers are leads, not conclusions — check the cited source before quoting it in a decision doc; every new reviewed research artifact gets added on completion, with its metadata header; a "thin evidence" answer is a research-backlog item — route it to your discovery planning. Assign an owner for the monthly hygiene pass: add what's missing, retire what's superseded.

Make it yours

• The interview-prep query: before each new interview, ask the repo "what have we already asked people like [persona] about [topic]?" — you stop burning the first twenty minutes re-learning what three colleagues already documented.
• Dovetail + NotebookLM split: keep Dovetail as the tagged system of record and export topic bundles into NotebookLM notebooks per initiative — the notebook becomes the initiative's evidence room, disposable when the initiative ships.
• Feed it forward: wire pb-02's synthesis docs and pb-17's counted-theme memos in on completion, so the repo compounds — the counted themes give your RAG quantitative spine to go with the interview color.

Quality check

• Citations resolveclick through five answers' sources; a citation to the wrong document is worse than no citation because it launders confidence.
• The refusal actually firesre-test the can't-answer questions monthly; contract drift toward helpful improvisation is the system's natural decay mode.
• Dates appear in answers, not just metadataan undated finding will be treated as current by every reader in a hurry.
• Conflicts surface as conflictsthe 2023 and 2025 findings appear side by side with dates, never blended into a fabricated consensus.
• The corpus has an owner and a hygiene cadencean unowned RAG degrades into a confident museum of expired findings within two quarters.