<!-- folio: 0 | title: Prologue | subtitle: The answer is not the beginning | question: What must be true before a machine is allowed to sound certain? -->

## Prologue — The answer is not the beginning

There is a small deception in the usual diagram of retrieval-augmented generation. A question enters on the left. A retriever fetches several passages. A language model produces an answer on the right. Three boxes, two arrows, one satisfying sense of completion. The diagram is not false, exactly. It is false in the way a map of a river is false when it draws only the water and omits the weather, the watershed, the dams, the farms, and the people downstream.

I began these notes with a simpler question than “Which RAG architecture is best?” I wanted to know what must be true before an answer deserves our confidence. That question changes the shape of the subject. It forces us to look behind the retriever at the documents that were admitted, parsed, versioned, divided, embedded, indexed, and authorized. It forces us to look beyond the generator at the claims that were supported, the citations that truly entailed them, the uncertainty that was hidden, and the person who must live with the result. RAG is not a clever prompt placed in front of a vector database. It is a chain of custody for evidence.

<aside class="margin-note">The central habit of this notebook: whenever a system looks intelligent, trace the evidence backward until the intelligence becomes an inspectable sequence of choices.</aside>

The word *retrieval* suggests a library. The metaphor is useful if we refuse to make the library magical. Its shelves have an acquisition policy. Some books arrive late. Some are duplicates. Some are hostile pamphlets dressed as reference works. A torn page may preserve the sentence we need while losing the heading that tells us what the sentence means. A catalogue can be fast and still point to the wrong edition. The reading desk has limited space. The writer seated there may ignore a useful passage, be distracted by an irrelevant one, or confidently remember something that contradicts the page.

Once the metaphor is made honest, nearly every RAG problem finds a place. Parsing determines what survives the doorway. Chunking determines what can be carried to the desk. Sparse and dense indexes are different catalogues. Rerankers are the librarian’s second look. Context packing arranges the desk. The model is a reader and writer with prior memories of its own. Citations are a claim about which page supported which sentence. Evaluation is the audit performed after the reader has gone home. Security is the recognition that not every page is benevolent and not every reader has permission to see every shelf.

<div class="sketch">
<svg viewBox="0 0 980 330" role="img" aria-labelledby="river-title river-desc" xmlns="http://www.w3.org/2000/svg">
  <title id="river-title">The evidence river</title>
  <desc id="river-desc">A hand-drawn path from sources through corpus, search, context, answer, and consequences, with feedback returning upstream.</desc>
  <defs>
    <filter id="rough"><feTurbulence baseFrequency="0.018" numOctaves="2" seed="8" result="noise"/><feDisplacementMap in="SourceGraphic" in2="noise" scale="2.2"/></filter>
    <marker id="arrow" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto"><path d="M0,0 L0,6 L9,3 z" fill="#2b5f91"/></marker>
  </defs>
  <path d="M75 172 C160 72, 225 265, 326 154 S493 74, 582 160 S747 270, 900 150" fill="none" stroke="#2b5f91" stroke-width="5" stroke-linecap="round" marker-end="url(#arrow)" filter="url(#rough)"/>
  <g fill="#fbf5e8" stroke="#243247" stroke-width="2" filter="url(#rough)">
    <rect x="25" y="116" width="122" height="70" rx="9"/><rect x="205" y="198" width="132" height="70" rx="9"/>
    <rect x="382" y="70" width="128" height="70" rx="9"/><rect x="559" y="188" width="132" height="70" rx="9"/>
    <rect x="752" y="90" width="158" height="70" rx="9"/>
  </g>
  <g fill="#243247" font-family="Bradley Hand, Segoe Print, cursive" font-size="19" text-anchor="middle">
    <text x="86" y="145">sources</text><text x="86" y="168" font-size="13">time · trust · ACL</text>
    <text x="271" y="227">corpus</text><text x="271" y="250" font-size="13">parse · divide · index</text>
    <text x="446" y="99">search</text><text x="446" y="122" font-size="13">recall · rank · stop</text>
    <text x="625" y="217">context</text><text x="625" y="240" font-size="13">select · order · budget</text>
    <text x="831" y="119">answer</text><text x="831" y="142" font-size="13">claims · citations · action</text>
  </g>
  <path d="M860 201 C770 314, 316 318, 122 219" fill="none" stroke="#c65f5a" stroke-width="2.5" stroke-dasharray="8 7" marker-end="url(#arrow)" filter="url(#rough)"/>
  <text x="485" y="310" fill="#c65f5a" font-family="Bradley Hand, Segoe Print, cursive" font-size="16" text-anchor="middle">evaluation and incidents must flow back upstream</text>
</svg>
<div class="sketch-caption">The visible answer is the river mouth. Most causes live upstream.</div>
</div>

### A field notebook, not a leaderboard

The literature is rich enough now to tempt us into chronology without understanding: one paper after another, each reporting a gain, each defining its own corpus, reader, retrieval budget, prompt, and judge. Those results matter, but they do not form a single race. A method that wins on short factoid questions over a frozen Wikipedia snapshot may be a poor design for changing policies in private PDFs. A graph can reveal relations in a corpus whose structure matters and waste extraordinary effort where ordinary passages already answer the question. Long context can rescue evidence a retriever misses and can also bury a model in distractors. Agentic search can resolve a multi-hop question and can spend ten calls manufacturing the appearance of diligence.

So these pages do not crown a universal champion. They ask, at every turn, what was held constant, where the gain entered the chain, and what new failure mode arrived with it. We will distinguish a retrieval score from an answer score, and both from a supported answer. We will separate relevance from utility: a passage can resemble the query yet contribute nothing to the final reasoning, while an apparently indirect passage may supply the missing premise. We will treat cost, latency, freshness, access control, and deletion not as production footnotes but as part of the system’s meaning.

<div class="field-question">If two systems return the same answer, but only one can identify the exact source version and span that supported every external claim, did they perform the same task?</div>

The answer is no, and the difference is the reason RAG exists. A language model can already produce fluent text. Retrieval earns its complexity only when it changes the epistemic character of that text: when knowledge can be updated without retraining, private evidence can be used without pretending it was learned globally, claims can be inspected, absence can be recognized, and mistakes can be corrected at the source. If the system merely decorates remembered prose with nearby links, it has reproduced the appearance of scholarship without its discipline.

This is why the smallest useful unit in the notebook is not the answer. It is the **claim–evidence relation**. Consider the sentence: “The policy changed in May, applies to contractors, and requires a review every ninety days.” It contains at least three propositions. One source may establish the date, a second the population, and a third the review interval. A single citation at the end can be visually plausible while supporting only one proposition. Claim-level provenance makes that ambiguity visible. It also gives evaluation something concrete to measure: Was the claim correct? Was there sufficient evidence in the corpus? Was it retrieved? Did the model use it? Does the cited span entail it? Was the source authoritative at the relevant time?

### The four losses

When an answer fails, people often say “the model hallucinated,” compressing the entire river into its final bend. A more useful diagnosis follows four losses. First comes **corpus loss**: the evidence never entered the usable collection, perhaps because a parser discarded a table, an update had not arrived, or authorization metadata was broken. Then comes **retrieval loss**: useful evidence existed but the search process did not surface it. Next is **context loss**: the evidence was retrieved but removed, truncated, poorly ordered, or drowned in distractors before generation. Last is **generation loss**: sufficient context reached the model, yet the answer ignored it, miscombined it, overgeneralized it, or cited it dishonestly.

These losses compose. Improving the last stage cannot repair evidence that vanished at the first, and measuring only the final answer cannot tell us which stage to change. The practical purpose of an evaluation harness is therefore not to issue a grade. It is to preserve enough traces that a failure can be walked backward.

<div class="observation">A RAG trace should make counterfactual questions cheap. What would the reader have answered with gold evidence? What would the ranker have done with the correct chunk among its candidates? What changed when one distractor was removed? Without those replays, “improvement” is mostly guesswork.</div>

The four-loss model also explains why stronger generation sometimes hides worse retrieval. A large model may answer from parametric memory even when the correct document was absent. The end-to-end score rises, while the system’s ability to update, cite, or honor a private corpus does not. The inverse happens when a strict grounding policy refuses to answer from memory: raw accuracy may fall, yet the product becomes safer and more correctable. Neither behavior is inherently right. The contract must say whether outside knowledge is permitted and how unsupported confidence is penalized.

### A question becomes a research program

Imagine a deceptively ordinary query: “Can a contractor working from Japan approve this customer’s refund today?” The words invite semantic search, but the real task is temporal, relational, and permission-sensitive. “Today” fixes an event time. “This customer” may determine a region and service tier. “Contractor” invokes an employment class. “Working from Japan” may implicate data-residency policy. “Approve” differs from “recommend.” A current policy, an exception table, and perhaps a customer-specific agreement must be joined. Some documents may be visible to the system but not to the contractor asking. A superseded policy may resemble the query more closely than the current one.

The first retrieval call is therefore not the beginning. Before it, the system must resolve identity, time, jurisdiction, vocabulary, and allowable sources. After it, the system may need to recognize insufficiency, reformulate a subquestion, fetch a structured record, compare versions, and stop before the search becomes noise. The final answer should distinguish what is permitted, what remains uncertain, and which evidence controls the decision. That single question touches almost every folio ahead.

<div class="experiment"><strong>Keep one difficult question beside every architecture diagram.</strong> Walk a real query through ingestion, authorization, retrieval, packing, generation, citation, and evaluation. At each boundary, write down the information that can be lost. A diagram that cannot carry the question is ornamental.</div>

### How to read these pages

The notebook opens as a journey because the subject is causal. We begin with the old machinery of information retrieval: terms, postings, probability, vectors, and the engineering of an evidence collection. We then let a generator sit beside the catalogue and watch new problems appear—context budgets, attribution, parametric conflict, and abstention. Search gradually becomes conditional and iterative; memory gives the system a past; time makes every fact provisional; untrusted documents turn the library into a security boundary. Only then do we build the evaluation and production disciplines capable of judging the whole.

There is no second book waiting behind these folios. The complete chronology, mathematical primer, source-by-source record, coverage matrix, decision guide, glossary, and executable experiments are stitched into the argument at the moment they become useful. Evidence leaves can be read straight through or folded after inspection; bench notes keep the code beside what it actually returned; binding notes disclose how the edition itself was assembled. The red thread is narrative, evidence, experiment, and provenance travelling together. A beautiful explanation without an evidence ledger is fragile. An exhaustive ledger without a line of thought is unreadable.

You will occasionally find handwriting in the margin. Those notes carry the judgments that do not fit neatly into taxonomies: the moment a benchmark comparison becomes unfair, the detail most likely to fail in production, the seductive abstraction that should be resisted. You will also find experiments. They are not toy demonstrations placed after the theory; they are small instruments for making the theory falsifiable.

<aside class="margin-note">Read with a pencil, even if the pencil is metaphorical. The right response to a RAG design is rarely “I believe it.” It is “show me the trace where this assumption breaks.”</aside>

### The promise we will hold the system to

By the final folio, a RAG system should be describable without mystical language. We should be able to name the corpus snapshot, the valid-time policy, the retrieval units, the index families, the candidate and evidence budgets, the query transformations, the reranker, the selection objective, the generator’s grounding contract, the citation granularity, the abstention rule, the threat model, the evaluation slices, and the operational envelope. We should know what happens when a document changes, when a user loses access, when two sources disagree, when no source answers, when an attacker inserts instructions, and when the model provider is unavailable.

That description will not make the system infallible. It will make its fallibility legible. This is a more modest ambition than artificial omniscience and a more useful one. The purpose of retrieval is not to give a model more things to say. It is to create an evidence path along which confidence can travel—and, when necessary, along which doubt can travel back.

<div class="chapter-bridge">Turn the page. Before a language model could borrow a memory, information retrieval had already spent decades learning how a collection resists being searched.</div>

<span class="page-number">FIELD NOTE 00 · THE EVIDENCE PATH</span>
