AI-Augmented Analyst branch (Finance galaxy) · Node AI0.04 of 7 · ~12 focused hours

Ask a general-purpose chat assistant a specific question about a specific company's most recent annual report and you have set a trap for it. The model was trained on a broad slice of the internet up to some cutoff date; your filing may postdate that cutoff, may never have been public training data at all, or may be one of thousands of similarly-named entities the model half-remembers and blends together. Ask it anyway, phrased confidently, and it will very often answer (fluently, specifically, and with no visible hesitation) because next-token prediction does not pause to check whether it actually knows something before continuing the sentence (AI0.01). Closing that gap is the job of the pages ahead. Retrieval-Augmented Generation (RAG) is the standard architecture for making an AI's answer depend on a document you hand it at the moment you ask, rather than on whatever it absorbed at training time.

The idea splits cleanly into four mechanical stages, and you will learn to trace all four by hand before you ever trust a tool that automates them. Turn text into embeddings, vectors that place similar meanings near each other. Split the document into chunks small enough to search individually. Retrieve the chunks whose meaning is closest to the question, then generate an answer that is instructed to use only what was retrieved. Every one of the seven "Document/PDF AI" tools in AI0.02's catalog, every "chat with your PDF" feature bolted onto a chat assistant, and every enterprise search-over-filings product runs some version of this pipeline. Understanding it is what lets you use any of them without being mystified by what "grounded" does and does not guarantee.

That guarantee is the other half of the story, and it is the more important half. RAG reduces hallucination. It does not eliminate it. A retrieval step can miss the right passage or rank a wrong one highest; a generation step can misread a number even in a passage it retrieved correctly. Grounding converts a model's unverifiable "trust me" into a checkable "here is the passage, here is the page", but converting a citation into a verified fact is still a step you perform, not one RAG performs for you. By the end you will have run a real "chat with a filing" session, in your own AI tool, against one Indian annual report and one US 10-K, and you will have built the habit of checking every answer against the actual page before you use it. Notation used throughout: ₹1 crore = 10 million rupees = 100 lakh; US figures in $ millions unless stated. Any specific product named below is dated as of 2026-07, verify current; the mechanics it illustrates are not.

Learning objectives

By the end you can:

Explain what a text embedding is (a vector that places passages of similar meaning near each other in a high-dimensional space) and why that lets retrieval work by meaning rather than by shared keywords.
Explain chunking: why a document must be split into pieces before it can be searched, the trade-off between chunk size and precision, the role of overlap, and the specific ways financial filings (tables, footnotes, multi-column layouts) break naive chunking.
Trace the full four-stage RAG pipeline end to end on a real question (embed the corpus, retrieve the top-k chunks, build a grounded prompt from them, and generate a cited answer) and name what each stage contributes and where each can fail.
Distinguish RAG from its two neighboring approaches, pasting a whole document into a large context window with no retrieval, and asking a model a question with no document at all, and choose correctly between the three given a document's length and your task.
Run a "chat with a filing" session in your own AI tool on both a real Indian annual report and a real US 10-K, demanding a citation for every figure and a "not found" answer where the filing is silent.
Apply the answer-with-citation discipline: treat a printed citation as a claim to check, not a fact to use, and re-locate every figure at its stated page before it enters your own work.
State and defend, precisely, the module's honest boundary: RAG reduces but never eliminates hallucination, because retrieval can miss or mis-rank a chunk and generation can still misread a chunk it retrieved correctly, and connect this to why Guardrail check #1 (Trace) never becomes optional.
Diagnose the recurring RAG failure modes (retrieval miss, chunk-boundary truncation, table/column misreads, entity or period conflation, parametric-memory contamination, citation-source mismatch) and match each to the Guardrail check that catches it.
Evaluate a document-chat tool using the AI0.02 rubric with RAG-specific questions added: does it retrieve or paste in full, where does an uploaded document go, and does it expose a verbatim, page-cited quote you can actually check.

Prerequisites & connections

Builds on. AI0.01 gave you the vocabulary reused here at a larger scale: tokens and embeddings as vectors, attention as "which earlier tokens matter," and the context window as working memory. It also gave you the payoff line (the model optimizes for plausible, not true), which explains why an ungrounded model answers confidently even when it should not. AI0.02 placed "Document/PDF AI" among the seven durable tool categories and gave you the evaluation rubric (what is it, good/bad at what, where does data go, how do you verify, cost/offline) that applies here specifically to retrieval tools. AI0.03 supplied the prompt discipline (Role·Context·Task·Format, asking for citations and a confidence level, structured output) that a grounded prompt is essentially built from, and here that discipline meets a real document for the first time. It also draws on the primary-source reading skill from Phase 0/M0.05 (navigating a full Indian annual report and a full 10-K) and on the "primary sources outrank every summary" working agreement that runs through the whole program (C1).

Feeds forward. AI0.05 treats a retrieval lookup as one of the "tools" an agent can call inside a plan→act→observe loop, so the retrieval-miss failure you learn to spot here recurs as a step inside a longer agentic chain. AI0.06, the branch's crown module, folds every failure mode named here (hallucinated numbers, unit/scale errors, fabricated citations) into its full taxonomy and drills detection until it is reflexive; nothing here is wasted, it is rehearsed at higher stakes. AI0.07's applied capstone leans on "chat with a filing" as one of its standing research accelerants, now assumed fluent. And every finance module from Phase 1 onward benefits directly: once you can ground a chat tool in a real filing and verify what it returns, first-pass reading of a dense footnote gets faster without your judgment ever leaving your own hands.

Core teaching content

Why ground an AI in a document at all

A chat model's only knowledge is whatever pattern it absorbed from its training corpus, frozen at a cutoff date (AI0.01). Three separate problems follow immediately for any question about a specific filing. First, the document may postdate the cutoff, a filing published after training simply does not exist in the model's weights, full stop, no matter how the question is phrased. Second, the document may never have been public training data at all, an internal memo, a paywalled research report, or in some jurisdictions even a public filing that the training pipeline never crawled. Third, and most dangerous, the model may have seen something adjacent and blend it in. Dozens of companies share an industry, a template, or even a name, and next-token prediction will happily complete a plausible-sounding sentence about "the company's segment revenue" using whichever pattern is statistically closest in its training data. You get no signal that it has done so.

RAG's answer to all three problems is the same: stop asking the model to recall, and instead hand it the actual text at the moment you ask, then instruct it to answer from that text alone. This does not require retraining the model (it works with any chat assistant that accepts a large prompt) and it is why "chat with your PDF" features exploded in popularity the moment context windows and retrieval tooling matured enough to make it cheap. The rest of the section builds the pipeline stage by stage; the one after it (Honest boundary) is the half of the lesson most learners skip, and the half most responsible for a mis-cited number ending up in a real memo.

Embeddings, revisited for retrieval

AI0.01 introduced the token embedding, a vector representing a single token's meaning in context. Retrieval uses the same idea one level up. A text-embedding model takes an entire passage (a sentence, a paragraph, a chunk) and compresses it into one dense vector, typically hundreds to a few thousand numbers. Those vectors are positioned so that passages with similar meaning sit close together in that space, regardless of whether they share any actual words. "The company's board approved a related-party transaction with its promoter entity" and "disclosure of dealings between the firm and its controlling shareholder's affiliate" would embed near each other despite sharing almost no vocabulary, because an embedding model is trained specifically to capture meaning, not spelling.

Closeness between two vectors is almost always measured with cosine similarity: the cosine of the angle between them, which ranges from −1 (opposite meaning) through 0 (unrelated) to 1 (identical meaning). Two vectors pointing in nearly the same direction (regardless of their length) score close to 1. This is the entire mathematical engine of retrieval: embed the question, embed every chunk once in advance, and rank every chunk by its cosine similarity to the question. It is worth computing this by hand at least once on a toy example; Worked example 1 does exactly that on a three-dimensional stand-in. The real thing (hundreds of dimensions, no human-readable axes) is not something you can eyeball, and the toy version is the only way to build real intuition for what "the model found a semantically close passage" actually means arithmetically. Contrast this sharply with plain keyword or full-text search, the mechanism behind Ctrl+F or a basic filing search box. Keyword search requires the literal term to appear, and misses every synonym, paraphrase, or cross-lingual match that embedding-based retrieval catches for free. That is exactly why RAG systems are typically built on embeddings rather than on keyword indexes alone.

Chunking: splitting the document before you can search it

You cannot embed an entire 200-page annual report as a single vector and expect it to be useful. One vector is one point in space, and a whole filing discusses dozens of unrelated topics. Its single embedding would sit in a vague, undiscriminating middle ground, close to almost everything and useful for finding almost nothing specific. Chunking solves this by splitting the document into smaller pieces (commonly a few hundred to roughly a thousand tokens each) each of which gets its own embedding, so retrieval can rank dozens or thousands of specific candidates instead of one blurred whole.

Chunk size is a real trade-off, not a default to leave unexamined. Chunks that are too small lose context: a number without the sentence that gives it a unit, or a bullet point without the heading that scopes it, embeds ambiguously and retrieves poorly. Chunks that are too large dilute precision: a chunk covering an entire footnote plus the two notes around it embeds as an average of three topics, so a query about one specific clause inside it may rank lower than a shorter, more focused chunk elsewhere that only partly matches. The common mitigation is overlap (letting adjacent chunks share a trailing/leading slice of text (commonly 10–20% of the chunk length)) so that a fact sitting near a boundary is very unlikely to be fully severed from its context in every chunk that touches it.

Financial filings create chunking failures that a generic blog post never would. A table split naively by character count can separate a number from the column header above it or the unit note below it (₹ in crore, $ in thousands), the text extracted from a table is not the table; it is a scrambled sequence of cell contents unless the chunker is table-aware. Multi-column PDF layouts, common in annual reports with sidebars, call-out boxes, and running footers, can interleave unrelated text if the extraction reads left-to-right across columns instead of down each column first. Footnotes and cross-references ("see Note 32") often land in a different chunk than the number they qualify, so the qualifying exception is retrieved separately from the headline figure, if at all. None of this is a hypothetical concern reserved for exotic documents, it is the single most common reason a "chat with your 10-K" answer looks confident and cites a real page yet still gets the number wrong, and Worked example 2 walks through exactly this failure on a synthetic filing excerpt.

Indexing: the vector store

Once every chunk has an embedding, those (vector, chunk-text, metadata) triples need to live somewhere that supports fast similarity search across potentially millions of chunks, this is a vector index (sometimes called a vector database or vector store). The mechanism is a specialized nearest-neighbor search structure; the durable fact to know is what it stores and why, not which specific product implements it, since that detail is genuinely perishable and beside the point for using the tool well. What matters far more for your own verification work is the metadata carried alongside each chunk's vector: page number, section or note number, fiscal year, and entity (standalone vs. consolidated) if the source distinguishes them. Metadata is what turns "chunk #4,281 was retrieved" into "Note 38, page 214, FY2025 consolidated statements", the citation you will actually check. A retrieval system with no page-level metadata can still answer questions; it just cannot be verified, which for this program's purposes makes it close to useless.

Retrieval: turning a question into the right chunks

At query time, your question is embedded with the same embedding model used to embed the chunks (a mismatched embedding model would place the question and the chunks in incompatible spaces, making similarity meaningless), then compared against every chunk vector in the index. The system returns the top-k most similar chunks (commonly somewhere between three and ten) as the evidence the generation step will be allowed to use.

Hold two things in your head simultaneously here, because the tension between them is the seed of the honest-boundary lesson two sections from now. First, retrieval is genuinely powerful: it turns "search a 300-page document for a concept, not a phrase" from a manual skim into a sub-second ranked list. Second, retrieval is a similarity search on wording and meaning, not a guarantee of relevance, sufficiency, or correctness. A chunk can score highly because it is topically adjacent to the question's phrasing while actually discussing the wrong fiscal year, the wrong subsidiary, or a superficially similar but legally distinct disclosure. Nothing in the retrieval step itself checks whether the returned chunk is the right one for your specific purpose, that check is yours, and it is exactly Guardrail check #2, Match.

Augmentation: building the grounded prompt

The retrieved chunks are inserted directly into the model's context window, alongside your original question and an instruction that does the actual grounding work. A well-built augmentation step tells the model, in substance: answer using only the passages provided below; if the answer is not in them, say so explicitly; and cite exactly where in the provided passages the answer came from. That is prompt engineering (AI0.03) with retrieved evidence spliced in as Context, not a separate technology, and it is precisely why the RCTF pattern you already own transfers directly. Role is "you are extracting facts only from the attached passages"; Context is the retrieved chunks themselves; Task is the specific question; Format is a citation-bearing answer with an explicit "not found" fallback. Every "chat with your document" product you will ever use is, underneath its interface, running some version of exactly this augmented prompt.

Generation: the grounded answer, and what "grounded" does and doesn't mean

The model now produces an answer conditioned on everything in its (now much fuller) context window. Calling this answer "grounded" means the model was instructed to derive it from the supplied passages rather than from its parametric memory. It is critically not a guarantee that the model actually complied, nor a guarantee that it read the supplied passage correctly. Three distinct things can go wrong at this final stage even when retrieval did its job perfectly and found exactly the right chunk. The model can misread a number inside a correctly retrieved passage, transposing digits, picking the wrong column out of a multi-year comparative table, or dropping a unit. It can blend in unrequested outside knowledge it happens to associate with the topic, producing an answer that sounds grounded but contains at least one claim the supplied passage never made. And it can misattribute a citation, printing a page number for a claim that actually came from a different passage, or from no passage at all. All three are demonstrated concretely in the worked examples that follow. It is the single most important subsection here to internalize before you go looking for a tool to try it in.

{ "skill": "Chatting with a specific filing to accelerate first-pass reading of a note, table, or policy",
  "use": "Upload or paste an annual report or 10-K into a document-chat tool and ask targeted, decomposed questions instead of skimming the whole filing yourself first — the tool locates and drafts an answer, you verify it.",
  "tools": ["Document/PDF AI — Claude (file upload), ChatGPT (file upload), NotebookLM", "Chat assistants with large context — for a single filing short enough to paste whole"],
  "prompt": "You are extracting facts only from the attached document, not from prior knowledge. This is <COMPANY>'s <annual report / Form 10-K> for FY<YEAR> (attached). Find <SPECIFIC FACT, e.g. the revenue-recognition policy for long-term contracts>. Quote the exact sentence(s) verbatim, and give the note/section number and page. If this is not present in the attached document, respond exactly: 'Not found in the provided document.'",
  "verify": "Open the actual filing at the cited page and confirm the quoted sentence genuinely appears there, and that figure + unit/scale + fiscal period + entity (standalone vs consolidated) all match what you need (Guardrail 1-5, checks #1 and #2 first).",
  "diy": "You must already be able to navigate a filing's own table of contents/index well enough to find that same note unaided (M0.05) — this tool saves the search, not the judgment of whether the found passage actually answers your question." }

The honest boundary: RAG reduces, never eliminates, hallucination

Say the payoff line once, plainly, because everything else here orbits it: grounding a model in a document lowers the rate and severity of hallucination, but it does not, and cannot, eliminate it. Six distinct residual failure surfaces survive even a well-built RAG system, and you should be able to name each one on demand:

Retrieval miss. The chunk that actually answers the question exists in the index but was not retrieved, it was phrased too differently from the question, or a more superficially similar but wrong chunk outranked it.
Wrong-chunk ranking. A plausible-but-irrelevant chunk scores higher than the correct one, the classic case is a query about "this year's" figure retrieving a chunk about last year's, because both discuss the same line item using nearly identical language.
Chunk-boundary truncation. Chunking severed a number from its unit, its qualifying clause, or its footnote reference, so even a correctly retrieved chunk carries an incomplete fact.
Generation misreads a correct chunk. The single most common real-world failure: the right passage was retrieved, but the model transposed a digit, picked the wrong column from a multi-year table, or dropped a "crore"/"million"/"thousand" scale marker.
Parametric-memory contamination. The model blends genuinely retrieved text with something it remembers from training about the company, the industry, or a similarly named entity, producing an answer that is partly grounded and partly not, with no visible seam between the two.
Citation-source mismatch. The printed citation (page, note number) does not actually correspond to where the claim came from, sometimes because the generation step lost track internally, occasionally because it was invented outright.

The honest way to describe RAG's real contribution, given all six, is this: it converts an unverifiable "trust me" into a checkable "here is the passage and the page." That conversion is genuinely valuable (it is the difference between having nothing to check and having something concrete to check) but the checking itself is a step a human still performs. This is exactly why Guardrail check #1, Trace, never becomes optional just because a tool is "RAG-based" or "grounded." A citation is an invitation to verify, never a substitute for verifying. Worked examples 3 and 4 make this concrete: one shows the full pipeline working correctly, the other shows it failing at the generation stage on a passage it retrieved perfectly.

Answer-with-citation discipline

Turn the honest boundary into a repeatable habit with five checks, the same Primary-Source Guardrail used everywhere in this program, applied specifically to a grounded answer:

Trace. Never use a figure or claim until you have opened the actual cited location and confirmed it exists and says what was claimed. No citation, no use, and a citation you have not personally opened counts as no citation.
Match. Confirm figure, unit/scale, fiscal period, and entity (standalone vs. consolidated) all agree between the AI's answer and the actual source. This single check catches the two most common RAG failures in financial documents: unit/scale drops (₹ crore read as a bare number) and period or entity conflation (this year's figure blended with last year's, or the parent's with the group's).
Recompute. Any ratio, growth rate, or derived figure the tool computed for you, recompute it yourself from the two raw numbers it cited. An AI that cites two correct source figures can still state an incorrect result of arithmetic on them, or apply the wrong formula.
Date-check. Confirm the filing you uploaded is actually the one you intended (the current fiscal year's filing, not last year's draft sitting in the same folder) and, for any claim the tool volunteers without a citation, treat it as potentially resting on the model's training-time knowledge rather than your document.
Cite. Record the exact location (page, note, section) in your own working notes, in a form a reviewer could re-open without redoing your search, the point of grounding was to make this possible; do not throw that away by paraphrasing without the pointer.

{ "skill": "Cross-checking a RAG answer's citation against the actual filing page before using the figure",
  "use": "Force the tool to expose the exact evidence behind a claim, then verify that evidence directly against the source document, rather than accepting a page number as proof.",
  "tools": ["Document/PDF AI — the same tool used to generate the answer", "A plain PDF reader with Ctrl+F/text search — deliberately NOT an AI tool, this is the human verification step"],
  "prompt": "For the figure/claim you just gave me, quote the exact sentence or table row it came from, verbatim, and give its page and note/section number. If you cannot produce an exact quote, say so instead of restating the claim.",
  "verify": "Open the filing at that exact page. Confirm the quoted text genuinely appears there (not paraphrased), and that it matches on unit/scale, fiscal period, and entity (Guardrail #2). Discard anything that fails this check, however confident the original answer sounded.",
  "diy": "You must be able to recognize genuine filing language when you see it — enough familiarity with how a real annual report or 10-K actually reads (M0.05) to tell a real quote from a smoothly paraphrased near-miss." }

RAG vs the alternatives: when to use what

RAG is one of three ways to get an AI to answer a question about a specific document, not the only way, and picking the wrong one wastes effort or introduces needless risk. Full-context paste puts the entire document directly into the prompt with no retrieval step at all. It is the simplest option and, for a document that comfortably fits the tool's context window, often more faithful than RAG for a single-document task, because nothing is filtered out before the model sees it. The trade-off is token cost, and it still requires the same verification discipline: a big context window buys availability, not correctness. RAG becomes necessary once the corpus exceeds any practical context window: years of filing history, a folder of many companies' filings, an internal knowledge base you want to query repeatedly. Embedding and indexing once, then retrieving cheaply many times, is the only practical way to make that corpus searchable at all. Pure ungrounded chat (no document, no retrieval, just the model's training-time knowledge) is appropriate only for generic conceptual questions ("what does a debt covenant usually restrict?") and never for a specific number, precisely because that is where AI0.01's fluent-wrong-answer failure mode lives unchecked.

A rough, usable rule of thumb: estimate roughly 1.3 tokens per word of the source, multiply by page count and words-per-page, add a few thousand tokens of overhead for the prompt and answer, and compare the total to your tool's context window. Comfortably under the window with a single document → full-context paste. Meaningfully over it, or you have many documents you will query repeatedly → RAG. Worked example 5 runs this arithmetic on two contrasting real-shaped scenarios.

{ "skill": "Deciding fast whether a research task needs full-context paste or a real RAG/document-chat tool",
  "use": "Before starting a research task on one or more filings, estimate the token budget and pick the simpler, more verifiable option (full-context) whenever it actually fits, reserving RAG for corpora that genuinely exceed a single context window.",
  "tools": ["Chat assistants with a large context window — for full-context paste of one or a few documents", "Document/PDF AI / research-agentic tools with multi-document retrieval — for a corpus too large to paste"],
  "prompt": "I am giving you <N> document(s) totalling approximately <PAGE COUNT> pages. Confirm whether you are treating this as full-context (you have the complete text of every document) or as a retrieval index (you will only see excerpts per question). If retrieval, tell me how many chunks you will search per question.",
  "verify": "If the tool confirms retrieval mode, treat every subsequent answer as subject to retrieval-miss risk (Guardrail #1) even when it cites a page — ask it to also state whether it searched all uploaded documents or only some. If it cannot answer this, assume the narrower, more skeptical case.",
  "diy": "You must be able to estimate a document's token count from its page count and words-per-page yourself (roughly words x 1.3), so you can sanity-check the tool's own claim about how it is handling your documents." }

Setting up your own chat-with-a-filing session

The Applied mini-project below walks this in full, but preview the shape of it now so the worked examples that follow read as rehearsal for something you will actually do. You will pick a document-chat tool: any "Document/PDF AI" category tool from AI0.02's catalog with file-upload support. You will obtain one real Indian annual report and one real US 10-K from their actual primary sources, meaning a company's own investor-relations page, BSE/NSE corporate filings, the MCA21 portal, or SEC EDGAR's full-text search for the US side. Then you upload each in turn and run a short ladder of questions that escalates deliberately: from a single stated fact, to a fact requiring you to locate a specific footnote, to a computation across two retrieved figures, to a question the filing does not answer at all. That last question is not filler: it is the fastest single test of whether your tool's silence can be trusted as much as its answers.

Common mistakes & how experts think differently

Trusting an answer because it "has a citation." A page number and a note number look identical whether they are accurate or fabricated; a citation is a claim to check, not evidence you have checked. The novice stops at "it gave a source"; the expert opens the source before the figure enters any of their own work, every time, without exception for a tool that "usually gets it right."
Equating "the AI read the whole document" with "the AI understood the whole document." Even a full-context, non-RAG approach that never drops a single page can still misread a table's column headers or silently skip a qualifying footnote, a larger context window buys availability, not comprehension. The expert applies the same verification discipline to a full-context answer as to a retrieved one; only the shape of the risk changes (no retrieval miss, but generation misreads remain fully possible).
Ignoring chunk-boundary truncation. A number that arrived without its unit, or a clause that arrived without the exception one sentence later, produces an answer that is technically "grounded" and quietly wrong. The novice accepts the answer as stated; the expert notices when a retrieved passage feels like it is missing its own qualifying context and asks the tool to show the surrounding text, not just the matched sentence.
Confusing "the model cited a page" with "the model correctly extracted the number on that page." Page-level citation is necessary for verification but nowhere close to sufficient, the figure, unit, period, and entity must all still match (Guardrail #2). The expert's default posture toward any cited figure is "unverified until I have personally matched all four," not "cited, therefore correct."
Asking one broad question instead of a decomposed, citation-demanding one. "Summarize the risks" invites a fluent, hard-to-verify paragraph blending several sources; "what is the single largest customer-concentration risk disclosed, quoted verbatim with its page" invites a checkable answer. The novice treats a document-chat tool like a search engine; the expert treats it like a witness being deposed, narrow questions, demanded quotes, an explicit "I don't know" option always on the table.
Believing grounding eliminates hallucination because the tool "read the actual document." This is the single myth these pages exist to correct. The expert's mental model keeps six distinct failure surfaces in view (retrieval miss, wrong-chunk ranking, chunk truncation, generation misreads, memory contamination, citation mismatch) and never collapses them into "it's grounded, so it's fine."

The thread through all six: RAG changes what there is to check, never whether checking is required. That discipline, more than any specific tool, is the real subject here.

Worked examples

Two synthetic, illustrative companies recur through these examples. Konkan Speciality Chemicals Limited is a fictional BSE/NSE-listed Indian specialty-chemicals manufacturer. Meridian Fleet Systems, Inc. is a fictional US industrial-logistics-equipment maker filing a Form 10-K. Neither is a real listed company. Every filing excerpt attributed to them below is written for these pages and must not be mistaken for a real disclosure. When you reach the Applied mini-project, you will run the identical exercise on a real Indian annual report and a real US 10-K of your own choosing.

Worked example 1: Cosine similarity by hand: which footnote answers the question? (India, ₹)

Konkan Speciality Chemicals Limited's FY2025-26 annual report has been chunked and embedded. A learner asks: "What related-party transactions did the company disclose?" Three candidate chunks are in the index. To make the arithmetic doable by hand, this example uses a toy three-dimensional embedding space with axes loosely standing for (1) legal/governance/related-party language, (2) financial-performance/accounting-policy language, (3) ESG/other narrative language, a teaching simplification only; a real embedding model uses hundreds of dimensions with no human-readable meaning at all.

Query vector q = (0.80, 0.10, 0.10). Candidate chunks: A, the related-party-transactions footnote (Note 38), vector (0.75, 0.15, 0.05); B, the revenue-recognition accounting policy note, vector (0.20, 0.90, 0.05); C, the CSR/ESG section, vector (0.10, 0.10, 0.95).

Solution. Cosine similarity is the dot product divided by the product of the vectors' magnitudes. |q| = √(0.80²+0.10²+0.10²) = √0.66 = 0.8124.

For A: q·A = 0.80×0.75 + 0.10×0.15 + 0.10×0.05 = 0.60+0.015+0.005 = 0.620. |A| = √(0.75²+0.15²+0.05²) = √0.5875 = 0.7665. cos(q,A) = 0.620 ÷ (0.8124×0.7665) = 0.620 ÷ 0.6228 = 0.995.

For B: q·B = 0.80×0.20+0.10×0.90+0.10×0.05 = 0.16+0.09+0.005 = 0.255. |B| = √(0.04+0.81+0.0025) = √0.8525 = 0.9233. cos(q,B) = 0.255 ÷ (0.8124×0.9233) = 0.255 ÷ 0.7501 = 0.340.

For C: q·C = 0.80×0.10+0.10×0.10+0.10×0.95 = 0.08+0.01+0.095 = 0.185. |C| = √(0.01+0.01+0.9025) = √0.9225 = 0.9605. cos(q,C) = 0.185 ÷ (0.8124×0.9605) = 0.185 ÷ 0.7803 = 0.237.

Read it. The ranking is A (0.995) far ahead of B (0.340), far ahead of C (0.237). Chunk A, the related-party-transactions footnote, is retrieved, exactly as it should be. Notice what made this work: the query and Chunk A share almost no vocabulary overlap requirement whatsoever, the retrieval succeeded purely because both sit in a similar direction in the (toy) meaning space. Also notice how decisively a good match separates from the rest (0.995 vs. 0.340), real retrieval systems often see a similarly wide gap when the right chunk exists at all, which is part of why a weak top score (all candidates clustered low, as in Practice problem P13) is itself a useful warning sign.

Worked example 2: Chunking a table without losing the number (US, $)

Meridian Fleet Systems, Inc.'s Form 10-K contains a three-year comparative table in its Debt footnote:

	FY2025	FY2024	FY2023
Term loan, net of discount ($ millions)	210.4	238.9	251.2
Maximum leverage ratio covenant	3.25x	3.25x	3.50x

A naive, fixed-length chunker splits text every ~150 tokens regardless of structure. Because the table's row labels and the FY2025 column happen to fall right at that boundary in this filing's raw extracted text, the chunker produces two pieces. Chunk 7 ends with "...Term loan, net of discount ($ millions)". Chunk 8 begins with "210.4 238.9 251.2 Maximum leverage ratio covenant 3.25x 3.25x 3.50x". The row header and its values are now in two separate chunks, and neither chunk alone states which number belongs to which fiscal year, because the column headers (FY2025/FY2024/FY2023) were themselves several rows above, likely in yet a different chunk.

Solution, the naive result. Asked "what was the term loan balance in FY2025?", a retriever working over these chunks might return Chunk 8 alone, because it holds the numbers, without Chunk 7 (which has the row label) and without the header row (the fiscal years). The generation step is then left to guess which of 210.4 / 238.9 / 251.2 is FY2025, or worse, to state one of the three confidently without any real basis for the choice.

Solution, the fix. Two independent mitigations are typically used together. Mitigation (1) is overlap: even a modest 20–30 token overlap between Chunk 7 and Chunk 8 would very likely have kept the row label attached to at least the first value. Mitigation (2) is table-aware chunking: treat a detected table as one indivisible unit, or reformat each row as a self-contained sentence before chunking, e.g. "In FY2025, the term loan balance, net of discount, was $210.4 million, with a maximum leverage ratio covenant of 3.25x". The fiscal year, the label, and the value then always travel together, regardless of where a length-based cut would otherwise fall. Read it. Retrieval and generation cannot fix a fact that was severed before either ever ran. Chunking-stage decisions are upstream of everything else in the pipeline, so a document-heavy verification habit should always ask, when a retrieved passage feels incomplete, whether the missing context is genuinely absent from the filing or was simply chunked away.

Worked example 3: The full pipeline, end to end, on one question (India, ₹)

Question: "What was Konkan Speciality Chemicals' related-party transaction value with its promoter entity in FY2025-26, and what is the source?"

Stage 1 is embed. The question is embedded with the same model used for the corpus, producing a query vector directionally similar to Worked example 1's q.

Stage 2 is retrieve. The index returns its top-3 chunks by cosine similarity. Rank 1 (score 0.99): Note 38, "Related Party Disclosures," stating in part. "Purchases from Konkan Promoter Trading LLP, a promoter group entity, amounted to ₹18.40 crore in FY2025-26 (previous year: ₹14.05 crore)." Rank 2 (score 0.61): the Corporate Governance Report's promoter shareholding table (topically adjacent, not the answer). Rank 3 (score 0.44): the CSR note (weak match, clearly not relevant).

Stage 3 is augment. The system builds a prompt containing the question and all three retrieved chunks with their metadata (Note 38, page 187; Governance Report, page 42; CSR Note, page 96). It also carries an instruction to answer only from the supplied text, cite the specific chunk used, and state "not found" if none of the three actually answer the question.

Stage 4 is generate. The model produces: "Per Note 38 (Related Party Disclosures, page 187), purchases from Konkan Promoter Trading LLP totalled ₹18.40 crore in FY2025-26, up from ₹14.05 crore in the prior year."

Verification runs the whole Guardrail 1–5 sequence. Check #1 Trace: open page 187 and confirm Note 38 exists and reads as quoted, which it does. Check #2 Match: figure ₹18.40 crore, unit crore (not lakh or plain rupees), period FY2025-26, entity Konkan standalone (Note 38 is in the standalone financial statements section), all agree with what the question needed. Check #3 Recompute: the year-over-year change, 18.40 ÷ 14.05 − 1 ≈ 31.0% growth, is arithmetic you can check yourself if the tool had stated a growth rate (here it only stated the two raw figures, which is itself good practice on the tool's part: fewer derived numbers to independently verify). Check #4 Date-check: confirm this is genuinely the FY2025-26 filing you intended, not a prior year's draft. Check #5 Cite: record "Note 38, p.187, FY2025-26 AR" in your own notes. Read it. Every stage worked correctly here; this is what a clean RAG answer looks like. It is also exactly why Worked example 4's failure, immediately following, matters: a clean-looking answer of this same shape can still be wrong, which is the entire reason verification cannot be skipped just because an answer "looks like this one."

Worked example 4: Grounded, cited, and still wrong (US, $)

Meridian Fleet Systems' 10-K, Item 8, contains this correctly-chunked, correctly-retrieved passage: "Net sales for fiscal 2025 were $551.2 million, compared to $612.7 million in fiscal 2024 and $598.4 million in fiscal 2023, a year-over-year decrease of 10.0% in fiscal 2025."

A learner asks: "How did Meridian's net sales trend in the most recent fiscal year?"

The flawed answer comes back like this: "Meridian's net sales grew in fiscal 2025, reaching $612.7 million, according to the FY2025 10-K (Item 8, p. 52)." Retrieval worked perfectly: this is exactly the right passage, correctly cited to the right page. But generation read the wrong column of a three-year comparative sentence, reporting FY2024's figure ($612.7 million) as if it were FY2025's, and consequently getting the direction of the trend backwards (claiming growth when the passage itself states a 10.0% decrease).

Verification catches it. Check #1 Trace: open page 52, and the sentence is there, exactly as retrieved. Check #2 Match: this is the check that fails, because the period does not match. The source's own words state the FY2025 figure is $551.2 million and explicitly call it a decrease; the AI's answer swapped in the FY2024 figure and inverted the direction. No part of the citation was fabricated: the failure is a misread within a perfectly real, perfectly cited passage. Read it. This is the honest boundary in its purest form: retrieval did its job, the citation is accurate down to the page number, and the answer is still wrong. No amount of trusting the citation would have caught this, only opening page 52 and reading the sentence yourself would, which is precisely Guardrail check #2 doing the work no automated grounding step can do for you.

Worked example 5: When does a document actually require RAG? (India, ₹)

Two research tasks, two very different token budgets. Task A: you want to ask a single question about Konkan Speciality Chemicals' standalone-only annual report: 64 pages, roughly 500 words per page. Estimated tokens: 64 × 500 = 32,000 words × 1.3 ≈ 41,600 tokens. A modern document-chat tool with a 128,000-token context window has 128,000 − 41,600 = 86,400 tokens of headroom even before subtracting a few thousand for the question and answer, the entire report fits with room to spare. Task B: you want to track a trend across Meridian Fleet Systems' last ten years of 10-Ks, each roughly 180 pages at a similar word density: 180 × 500 × 10 = 900,000 words × 1.3 ≈ 1,170,000 tokens, roughly nine times the 128,000-token window, before any overhead at all.

Solution. For Task A, full-context paste is the better fit: the whole document fits comfortably, so pasting it directly avoids retrieval-miss risk entirely for a single targeted question, at a token cost you can easily afford. For Task B, full-context paste is not an option at any reasonable tool tier, because the corpus is roughly nine times too large. RAG is the only workable approach here, not a preference: chunk and embed the ten filings once, then query the resulting index as many times as the trend analysis requires. Read it. The decision rule is arithmetic, not intuition. Estimate words × 1.3 for a rough token count and compare it against your specific tool's context window, which varies by product and tier and should always be treated as dated ("as of 2026-07, check current"). Let that comparison decide, not a general preference for either approach.

Worked example 6: Evaluating a document-chat tool with the RAG-specific rubric (US, $)

Applying AI0.02's tool-evaluation rubric specifically to a "chat with your 10-K" category of tool, using Meridian Fleet Systems' 10-K as the illustrative task.

Take the rubric one question at a time. What is it? A chat interface with document upload that retrieves relevant passages from the uploaded file(s) and answers with (in better implementations) page-level citations. Good at / bad at? Good at fast, targeted multi-question sessions across one or several documents, and at surfacing a specific footnote far faster than a manual skim. Bad at guaranteeing completeness on a very long single document, since retrieval can still miss a relevant passage, and often poor at faithfully extracting numbers from scanned or image-based tables, where OCR errors compound chunking errors. Where does the data go? Varies by product and by whether an enterprise/no-training tier is enabled. Check the provider's current data-usage policy before uploading anything not already public, and re-check it periodically, since these policies change (as of 2026-07, check the current figure for whichever tool you choose). How do you verify output? The decisive question: does the tool expose a verbatim quote and a page/section number for every claim, or only a paraphrase with no way to locate the source sentence? A tool that cannot produce a checkable quote on request should be treated as unverifiable regardless of how confident its prose sounds. Cost/offline? Typically subscription or per-use API pricing, and requires an internet connection, there is no meaningful offline "chat with your PDF" option as of this writing.

Read it. None of this evaluation required trusting a brand name. It is the same five questions from AI0.02, asked with one addition specific to retrieval tools: can it show its work, chunk by chunk, page by page? A tool that answers "no" to that question has told you everything you need to know about how much verification burden falls back on you.

Practice set

Work each problem before reading its solution. Figures and companies are illustrative unless a real primary source is named.

P1 (guided). Cosine similarity: US litigation query. A 10-K chat tool has embedded a query, "What litigation contingencies has the company disclosed?", as q = (0.85, 0.10, 0.05) using this module's toy three-axis space (legal/governance, financial-performance, ESG/other). Two candidate chunks: A, the Commitments & Contingencies footnote, at (0.80, 0.15, 0.05); B, the segment-reporting note, at (0.15, 0.85, 0.00). Compute both cosine similarities and state which chunk is retrieved.

Solution. |q| = √(0.85²+0.10²+0.05²) = √0.735 = 0.8573. For A: q·A = 0.85×0.80+0.10×0.15+0.05×0.05 = 0.68+0.015+0.0025 = 0.6975; |A| = √(0.64+0.0225+0.0025) = √0.665 = 0.8155; cos(q,A) = 0.6975 ÷ (0.8573×0.8155) = 0.6975 ÷ 0.6992 = 0.998. For B: q·B = 0.85×0.15+0.10×0.85+0.05×0 = 0.1275+0.085 = 0.2125; |B| = √(0.0225+0.7225) = √0.745 = 0.8631; cos(q,B) = 0.2125 ÷ (0.8573×0.8631) = 0.2125 ÷ 0.7400 = 0.287. Chunk A (0.998 vs. 0.287) is retrieved, decisively, since the query's dominant axis (legal/governance) matches A's dominant axis, while B is dominated by the unrelated financial-performance axis.

P2. Chunk-size trade-off. A fact spans one sentence that begins near the very end of a fixed 200-token chunk boundary. Compare two chunking schemes (200 tokens with no overlap, versus 200 tokens with 50-token overlap) for the risk of severing this fact, and explain why.

Solution. The no-overlap scheme is materially riskier: whatever falls after token 200 starts an entirely new chunk with zero shared text, so a sentence straddling the boundary is very likely split with no chunk containing it whole. The 50-token overlap scheme carries the last 50 tokens of each chunk into the start of the next, so a sentence beginning "near the end" of the boundary has a real chance of being fully contained in at least one of the two overlapping chunks. Overlap does not guarantee every fact survives intact (a sentence longer than the overlap window can still be split), but it substantially reduces the odds versus no overlap at all.

P3. Token-budget arithmetic. India. An Indian company's standalone annual report runs 82 pages, averaging 520 words per page. Using ~1.3 tokens per word, estimate the token count. If your chat tool has a 32,000-token context window and you must reserve 3,000 tokens for the system prompt, question, and answer, does the full report fit in one full-context pass? If not, by how much does it overshoot?

Solution. 82 × 520 = 42,640 words. 42,640 × 1.3 ≈ 55,432 tokens. Adding the 3,000-token reserve: 58,432 tokens required, against a 32,000-token window, it does not fit, overshooting by 58,432 − 32,000 = 26,432 tokens. Next move: either use a tool tier with a larger context window, or switch to a RAG/retrieval approach rather than a full-context paste, since the whole document cannot be presented at once on this tool.

P4. Diagnose a retrieval miss. A question asks specifically about "the FY2025 impairment charge." The retrieved top chunk instead discusses an FY2023 impairment in similar language, and the FY2025 discussion (which exists elsewhere in the filing) was not retrieved at all. Name the failure and the Guardrail check that would catch it before the wrong figure is used.

Solution. This is a retrieval miss / wrong-chunk ranking failure: the correct chunk exists in the index but a differently-dated chunk, more superficially similar in wording, outranked it. Guardrail check #2, Match catches it, checking that the retrieved passage's fiscal period actually matches FY2025, not FY2023, before using anything it says. The fix in practice is usually to make the question's period explicit and unambiguous in the prompt itself ("using only the FY2025 disclosures, ...") and, if the wrong year keeps winning, to ask the tool to retrieve and list all chunks discussing impairment across every year so you can pick the right one yourself.

P5. Diagnose a chunk-truncation failure. A retrieved chunk contains a number but not the sentence stating its unit (₹ crore vs. ₹ lakh vs. plain rupees), because the header sentence fell in the previous chunk. What should you do before using the number, and which Guardrail check governs this?

Solution. Do not use the number until its unit is confirmed, ask the tool to show the surrounding text (the chunk before and after), or open the source page directly and read the unit statement that governs the table or paragraph. This is Guardrail check #2, Match, specifically the unit/scale component: a number without a confirmed unit is not yet usable, no matter how confidently it was cited.

P6. Recompute a margin. A tool states: "Meridian Fleet Systems' gross margin for FY2025 was approximately 34%, from gross profit of $187.4 million on net sales of $551.2 million (10-K, Item 8, p. 52)." Recompute the margin from the two cited figures. Does it match?

Solution. 187.4 ÷ 551.2 = 0.3400, or 34.0%, the tool's stated figure matches. This is a case where verification confirms the answer rather than catching an error, which is the point: you run Guardrail check #3 (Recompute) every time, not only when you suspect a mistake, precisely because you cannot know in advance which answers will pass and which will fail.

P7. Unit/scale error. India. A tool summarizing Konkan Speciality Chemicals' FY2025-26 report states: "Related-party transactions with a subsidiary totalled ₹450, as disclosed in Note 38." The source table's column header reads "All amounts in ₹ crore unless otherwise stated." What is the likely error, and what is the corrected figure?

Solution. The tool dropped the unit: the table reports amounts in ₹ crore, so the true value is ₹450 crore (₹4,500,000,000), not a bare ₹450, a sum that small would be an implausible related-party transaction value for a listed manufacturer and should itself have been a red flag. This is exactly Guardrail check #2, Match, always confirm the unit/scale column header before accepting any bare number pulled from a table.

P8. Citation mismatch. A tool cites "Note 32, page 214" for a claim about deferred tax liabilities. You open the actual filing at page 214 and find Note 29, "Segment Information," with no mention of deferred tax anywhere on that page. What should you do, and what are the charitable versus uncharitable explanations for the mismatch?

Solution. Do not use the figure until you have located the actual correct note yourself (search the filing's index or use text search for "deferred tax" to find where it really is) or confirmed it is not present at all. The charitable explanation is pagination drift, the PDF's page count and the filing's own printed page numbers can differ, or the tool re-rendered the document and mis-tracked page numbers internally. The uncharitable explanation is an outright fabricated or internally mis-tracked citation. Either way, the remedy is identical: treat the figure as unverified and re-locate it before use (Guardrail checks #1 and #5).

P9. RAG vs. full-context, a mixed scenario. You want AI help on two tasks: (a) one specific accounting-policy footnote inside a single 60-page Indian annual report you have as one PDF, and (b) building a queryable base across 12 years of a US company's 10-Ks (12 separate ~150-page filings) to track a trend. For each, name the better-fitting approach and justify it with the token-budget argument.

Solution. Task (a): full-context paste. 60 pages × ~500 words × 1.3 ≈ 39,000 tokens, comfortably inside a modern large-context tool, and pasting the whole document avoids retrieval-miss risk entirely for one targeted question. Task (b): RAG is required. 12 × 150 pages × ~500 words × 1.3 ≈ 1,170,000 tokens, far beyond any practical single context window, and because you intend to query the corpus repeatedly, indexing once and retrieving many times is both the only feasible option and the more efficient one.

P10. Detecting memory contamination. Grounded on Meridian Fleet Systems' FY2025 10-K, a tool answers "What caused the drop in operating margin?" fluently, citing a page, but among its stated causes lists a supply-chain issue that is, in fact, real public news about a different company in the same industry, not anything in Meridian's own (synthetic) filing. How do you catch this, and what follow-up prompt forces the issue?

Solution. Ask the tool to quote, verbatim, the exact sentence supporting that specific claim, with its page number. If it cannot produce a real quote from the retrieved passage supporting the supply-chain claim, that claim is parametric-memory contamination (knowledge blended in from training, not from the document) and should be discarded from "what the filing says" or, if worth pursuing, independently verified against its own real primary source and cited as separate, ungrounded research, never attributed to Meridian's filing.

P11. RAG-specific tool evaluation. Before uploading an embargoed (not-yet-public) draft annual-report excerpt to a document-chat tool you have never used, which two AI0.02-rubric questions matter most, and why do they matter more here than for a plain chat window with no upload?

Solution. "Where does the data go?" matters more because uploading a whole document is a larger exposure than pasting a single sentence, confirm retention/training policy and whether a no-train or enterprise mode exists before uploading anything not already public. "How do I verify output?" matters more because a document-chat tool's entire value proposition depends on being checkable, specifically, does it expose page-level citations and verbatim quotes at all; a tool that cannot is far harder to trust with anything consequential, embargoed or not.

P12. Write a grounded-QA prompt. Using RCTF (AI0.03), write a prompt for a document-chat tool, after uploading Meridian Fleet Systems' 10-K, to find the maximum leverage-ratio covenant in its credit agreement. The prompt must force a citation and a "not found" fallback.

Solution. A model answer: "Role: you are extracting facts only from the attached document, not from prior knowledge. Context: this is Meridian Fleet Systems, Inc.'s Form 10-K for FY2025 (attached). Task: find the maximum leverage ratio (e.g., Debt/EBITDA) the company's credit agreement requires it to stay under, as disclosed in Liquidity and Capital Resources or the Debt footnote. Format: state the exact ratio and threshold, quote the exact sentence it comes from verbatim, and give the page/note number. If this is not present in the attached document, respond exactly: 'Not found in the provided document', do not estimate or use outside knowledge." Self-check against RCTF: Role present, Context present (the attached filing, named and dated), Task unambiguous (one specific figure), Format specified (citation + verbatim quote + explicit not-found fallback), all four boxes checked.

P13. Retrieval-confidence threshold. A retrieval system returns its top-3 chunks with cosine similarities 0.31, 0.27, and 0.22 for a question, and is configured to answer only when the top score exceeds 0.55, otherwise responding "not found." What should happen here, and why is a conservative threshold like this a good safety design even though it will sometimes decline a question the corpus could actually answer?

Solution. The system should respond "not found": 0.31 is well below the 0.55 threshold, meaning none of the retrieved chunks are a strong semantic match, and answering anyway would risk generating a fluent response from weak or irrelevant grounding. The trade-off is deliberate: a conservative threshold sacrifices some recall (occasionally declining a question the corpus genuinely could answer, if the true match happened to score just under the bar) in exchange for precision (never confidently answering from a poor match), a bias toward a safe, visible failure ("I don't know") over a dangerous, invisible one (a confident wrong answer).

P14. Match each failure to its Guardrail check. Match each scenario to the single Guardrail check (1–5) that most directly catches it: (a) a fabricated note/page citation; (b) ₹ crore reported as a bare number; (c) a percentage the model computed incorrectly from two correctly cited figures; (d) the retrieved chunk is from last year's filing, not the current one; (e) no location was recorded anywhere for a reviewer to re-check later.

Solution. (a) → #1 Trace (opening the cited location exposes the fabrication) and #5 Cite are both relevant, but Trace is the primary catch. (b) → #2 Match (unit/scale). (c) → #3 Recompute. (d) → #2 Match (period), with #4 Date-check relevant if the concern is the model's own knowledge cutoff rather than which filing year a chunk belongs to. (e) → #5 Cite.

P15. Entity/scope conflation. India. Konkan Speciality Chemicals' FY2025-26 annual report contains both standalone (parent-only) and consolidated (group, including three subsidiaries) financial statements. A tool's answer states the company's "total revenue," blending the standalone Note 24 revenue figure with a segment-revenue table that appears only in the consolidated section. Which Guardrail check is violated, and what single instruction in your original prompt would have prevented this?

Solution. Guardrail check #2, Match: specifically the entity/scope component: standalone and consolidated are two different reporting scopes with two different revenue figures, and blending them without disclosure is exactly the kind of scale/scope mismatch this check exists to catch. The preventing instruction: specify explicitly in the prompt, "answer using only the CONSOLIDATED financial statements, and state which statements your figures come from," forcing the tool to declare its scope and making the check trivial to run afterward.

P16. In your own words. In two to three sentences, using this module's own vocabulary, explain why "RAG reduces but never eliminates hallucination."

Solution (model answer). Grounding a model in retrieved passages removes one whole class of error (answering from nothing at all) but retrieval can still miss the right chunk or rank a wrong one highest, and chunking can sever a fact from the context that gives it meaning. Even when the exactly right chunk is retrieved, the generation step can still misread a number, a column, or a unit inside it, or blend in something the model remembers from training rather than the supplied text, so a citation is always a claim to verify, never a fact already checked.

Applied mini-project

Chat with a filing, verified: one India annual report, one US 10-K. This is the exercise every worked example above was rehearsal for, run for real, on a real document, in a tool of your own choosing. Tool names anywhere in this project are dated as of 2026-07, verify current; the method is not.

Do this, in order:

Pick your tool. Any "Document/PDF AI" category tool with file-upload support (per AI0.02's catalog), a general chat assistant with document upload, or a dedicated document-QA tool. Confirm it can expose page-level citations before you commit to it; if it cannot, pick a different one.
Obtain two real filings. (a) An Indian company's annual report as a PDF, from the company's own investor-relations page, BSE or NSE corporate filings/announcements, or the MCA21 portal. (b) A US company's Form 10-K, from SEC EDGAR's full-text search or the company's own investor-relations page. Pick a company of moderate size and a filing under roughly 150 pages for your first attempt on each side, so you can plausibly cross-check the tool by hand afterward.
Upload or paste each filing into your chosen tool, one at a time, in a fresh session per filing.
Run this exact five-question ladder on each filing, adjusting only the specific fact requested: Q1 (a stated fact). "What was total revenue for the most recent fiscal year, and on which page/statement did you find it?" Q2 (a specific note). "Quote, verbatim, the company's stated revenue-recognition accounting policy, with its note number and page." Q3 (a computation). "Using the two most recent fiscal years' revenue figures, compute the year-over-year growth rate, showing both source numbers and their pages." Q4 (a "not found" probe), deliberately ask something the filing does not contain (a segment the company does not operate in, or a year several years before the filing's history) and note whether the tool honestly says "not found" or fabricates an answer anyway. Q5 (a consistency check), ask Q1 again, worded differently, and confirm the answer is stable.
Build a verification table with one row per question (Q1–Q3, Q5): columns for the tool's answer, the page it cited, what you actually found at that page when you opened the real filing, whether they match, and the corrected value if they do not. Run all five Guardrail checks against each accepted answer.
Write one paragraph on Q4: did the tool correctly decline, or did it fabricate a fluent answer to a question its own document cannot answer? Either outcome is useful data about the tool: record which you got.

Deliverable and self-check. One completed verification table and Q4 write-up per filing (India and US), scored out of 10 as follows. Award 2 points if both an Indian annual report and a US 10-K were completed, not just one. Award 3 points if every accepted figure across both filings passed all five Guardrail checks, with the check recorded, not just asserted. Award 2 points if the Q4 "not found" probe was correctly diagnosed (honest decline vs. fabrication) and you noted which. Award 2 points if at least one genuine imprecision, near-miss, or outright error was caught and corrected in writing, on either filing; a suspiciously clean run on both filings is a reason to look harder, not a badge of tool quality. Award the last 1 point for a one-paragraph verdict on whether you would trust this specific tool for unsupervised use on a filing, and precisely why. Pass at 8/10 with no zero on any item.

Lab: open this node's guided Chat with a Filing project in the Practice tab, log your two filings' cited pages into the in-app verification worksheet, and pass its checks.

Reading & resources

The foundational research:

Lewis, Perez, Piktus, et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020), the paper that named and formalized the retrieve-then-generate architecture taught here end to end. [Free] [Advanced]
Ji et al., "Survey of Hallucination in Natural Language Generation", the broader taxonomy the "honest boundary" section above draws six specific failure surfaces from; read the sections on retrieval-augmented and grounded generation specifically. [Free] [Advanced]

Embeddings and vector search, explained without the math:

Jay Alammar, "The Illustrated Word2Vec" and "The Illustrated Transformer": carried over from AI0.01; reread the embedding-space intuition with retrieval specifically in mind before attempting Worked example 1 by hand. [Free] [Beginner–Intermediate]
Pinecone Learning Center, "Retrieval-Augmented Generation" and "What is a Vector Database?", accessible, practitioner-level explainers of chunking, indexing, and similarity search. [Free] [Intermediate]
LlamaIndex and LangChain's own RAG documentation, worth reading for the field's working vocabulary (loaders, chunkers, retrievers) even if you never write the underlying code; it is the dialect every RAG-adjacent tool description assumes. [Free] [Intermediate]

The primary sources you will actually ground against:

SEC EDGAR full-text search (sec.gov/edgar/search) and the XBRL "Frames" API, the US primary-source anchor for every 10-K exercise here, and where the Applied mini-project's US filing should come from. [Free] [Beginner–Advanced]
BSE and NSE corporate-announcements/filings pages, the MCA21 portal, and company investor-relations pages, the India primary-source anchor; a listed company's own IR page typically mirrors the same annual report PDF filed with the exchanges. [Free] [Beginner–Advanced]

Before you upload anything:

The data-usage and privacy documentation published by whichever chat or document tool you choose (every major provider publishes one), confirm what happens to an uploaded document, and whether a no-training or enterprise tier exists, before your second upload, not just your first. [Free] [Beginner]

Forward pointers within this branch:

AI0.03, the RCTF prompt pattern the grounded-QA prompts here are built directly from; revisit it before writing Practice problem P12's prompt if it feels unfamiliar.
AI0.06, the full failure-mode taxonomy and Guardrail drill, crowned at ≥90%; every failure surface named in the "honest boundary" section above reappears there at higher stakes and higher difficulty.
Simon Willison's writing on prompt injection, an uploaded or retrieved document is untrusted input the moment it can influence the model's behavior, not just its answer content; the Q4 "not found" probe above is a mild, benign cousin of the attack AI0.06 covers in full. [Free] [Intermediate]

Teach it back & journal

Feynman prompt. Explain to a colleague who has never heard of RAG why "the AI read the actual filing" is not the same guarantee as "the AI's answer about the filing is correct." Use Worked example 4 (Meridian Fleet Systems' net sales) as your concrete case: retrieval found exactly the right passage, the citation pointed to exactly the right page, and the answer was still wrong. If your colleague can, unprompted, name the specific stage that failed (generation, not retrieval) and explain why a bigger context window or a better retrieval index would not have fixed it, you have actually taught the honest boundary rather than just stated it.

Journal prompt. Run the Applied mini-project's five-question ladder on one filing you personally care about, a company you hold, follow, or are considering. Before you look at your verification table, predict in writing which of the five questions you expect the tool to get right without qualification, and which you expect to require a correction. Then run the exercise and compare your prediction to what actually happened. Write a short paragraph on what surprised you: did the tool fail somewhere you expected it to succeed, or succeed somewhere you expected it to fail? What does that gap tell you about which of your own instincts about AI reliability need recalibrating before AI0.06 puts them under real pressure?

This module's flashcards and mastery quiz are wired into the app: see the node's Quiz and Reviews.

Retrieval & RAG: Grounding AI in Filings & Documents