Grounding Claude in your data

Claude knows a great deal about the world and nothing about your world — your codebase, your policies, yesterday's incident. Every useful application closes that gap the same way: put your data in front of the model and make it answer from the data. This lesson covers the machinery Claude gives you for doing that well — citations above all — and the architectural fork every team hits: stuff the context, or build retrieval?

Citations: answers that carry their evidence

You met the citations flag in the previous lesson; here is why it should be on from day one in any document-answering product. With citations enabled, the response comes back as text blocks annotated with exactly which passage of which document supports each claim — page numbers for PDFs, character ranges for text. That transforms the product: users can verify instead of trust, and when an answer is wrong you can see whether the model misread a passage or the right passage was never there. It also transforms debugging — "retrieval fetched the wrong thing" and "the model misread the right thing" are different bugs with different fixes, and citations are how you tell them apart.

The fork: long context or retrieval?

Current Claude models accept up to a million tokens — several thousand pages — so the lazy architecture of "put everything in the prompt" genuinely works at sizes that used to demand infrastructure. The engineering question is when it stops being the right answer:

• Fits comfortably and is mostly stable? Stuff it. A product manual, a policy handbook, one repository's core modules. Combined with prompt caching — documents first, marker after them, questions last — the corpus is written to cache once and every question reads it at a tenth of the price. Simplicity wins: no pipeline, no index drift, nothing to debug at 2 a.m.
• Orders of magnitude too big, or changing constantly? Retrieve. A million support tickets cannot ride in a prompt. Retrieval-augmented generation — index the corpus, fetch the relevant slices per question, place only those in context — is the standard architecture, and it also buys you provenance at corpus scale: you know what the model saw because you chose it.

The honest heuristic: start with long context plus caching, and graduate to RAG when the corpus outgrows the window, freshness demands per-query lookup, or input cost at scale forces the issue. Teams that start with RAG for a corpus that fits in context pay a complexity tax for nothing. A useful middle rung before full RAG: let Claude retrieve with tools — give it a search_docs tool over your existing search index and let the agentic loop decide what to fetch; you get per-query freshness without building an embedding pipeline, at the cost of extra round trips.

The grounding contract

Whichever architecture you choose, the prompt pattern is identical, and it is the two-line core of every trustworthy Q&A system:

Answer using ONLY the provided documents. If the answer is not in them,
say so plainly — name what is missing rather than guessing.

Instruction plus abstention. The first line stops the model from blending your documents with its general training memory; the second converts the unanswerable case from confident fabrication into an honest gap. Add citations on top and every answer arrives with its evidence attached. When you review a grounded system that hallucinates, check these two lines first — they are missing more often than the retrieval is broken.

What to take into the next lesson

Citations for verifiability, long-context-plus-caching as the default architecture, tool-driven retrieval as the middle rung, and full RAG when scale or freshness demands it — always under the grounding contract. Retrieval engineering runs deeper than one lesson, and Nybble's Building RAG Systems course covers that path end to end. Next, a different kind of input entirely: Claude looking at a screen and doing what you would do with it.