How a Computer Finds the Right Page

You type a question into Claude Desktop. A few seconds later you get an answer, and next to it a page number. You open the page, and the answer is there.

This post is about what happened in between — explained from scratch. No prior knowledge assumed, and every term defined where it first appears.

It matters because the mechanism has failure modes, and you can only spot them if you know roughly how the thing works.

Start with what's broken

Ordinary search — the kind in every PDF reader — matches characters. Type "timeliness" and you get pages containing the letters t-i-m-e-l-i-n-e-s-s.

Which means you have to guess the words the author chose. If opposing counsel wrote "the motion was not filed within the period prescribed" and never used the word "timeliness," your search returns nothing. The passage is there. You asked for it. You didn't get it.

The reverse hurts too. Search a large record for "notice" and you get every page containing the word — hundreds of them, most about something else entirely.

Keyword search has no idea what anything means. It's a very fast, very literal clerk.

Embeddings: turning meaning into position

Here's the trick that fixes it, and it's genuinely clever.

A computer can't compare meanings. It can compare numbers, extremely fast. So the move is to convert meaning into numbers, in a way that preserves which things are alike.

An embedding model is a program that reads a passage of text and outputs a long list of numbers — a couple of thousand of them. Something like:

[ 0.021, −0.418, 0.770, −0.036, 0.512, … ]

Those numbers aren't random, and they aren't a code for the words. Think of them as coordinates. Two numbers would place a point on a map. Three would place it in a room. A couple of thousand place it somewhere you can't picture — but the arithmetic works the same regardless of how many there are.

The model has been trained so that passages meaning similar things land near each other, even when they share no words at all.

So "the motion was not filed within the period prescribed" and "the request was untimely" end up close together, because they mean nearly the same thing. Not because they look alike — they don't.

That's the whole idea: meaning becomes position, and position is arithmetic.

Why documents get chopped up

Notice the middle step. The page isn't embedded whole — it's split into overlapping passages first, usually a paragraph or two each.

There's a real tension here:

• Chunks too large, and the coordinates get muddled. A passage covering four unrelated topics points in an averaged direction that's nobody's answer.
• Chunks too small, and you lose context. A sentence beginning "This was not raised below" is useless when you can't see what "this" refers to.

Overlapping the chunks means an idea straddling a boundary appears whole in at least one of them. It's a compromise, and getting it right is a meaningful part of why one system finds things another misses.

Cosine similarity: how "close" is measured

If every passage is a point, similarity should just be distance — right?

Almost. There's a subtlety worth understanding, because it explains a behaviour you'll otherwise find odd.

Picture each passage not as a dot but as an arrow from the origin out to that dot. An arrow has two properties: the direction it points, and its length.

Roughly speaking, direction captures what the passage is about. Length captures something more like how much there is of it.

For finding things, we want the first and not the second. A one-line quote and a ten-page argument about the same subject should match each other. If we measured tip-to-tip distance, they'd look far apart — the long one reaches much further out — and we'd miss it.

So instead we measure the angle between the arrows, and ignore length entirely. The cosine of that angle gives a tidy score:

That's all "cosine similarity" means: how closely aligned are these two arrows. In practice, scores for legal text tend to sit between about 0.3 and 0.9.

The practical consequence: a two-sentence passage that is exactly on point can beat a five-page section that rambles around the topic. That's usually what you want, and it surprises people who expect "more text about the subject" to rank higher.

Same ruler for both sides

One non-obvious requirement. Your question goes through the same process — it gets turned into coordinates too, and then we look for stored passages pointing the same way.

For that comparison to mean anything, the question and the documents must be measured with the same embedding model. Different models produce different coordinate systems; a point from one tells you nothing about a point from another.

This is why changing the embedding model means re-indexing everything. It isn't an upgrade you can apply halfway. Half your corpus in one coordinate system and half in another produces a search that quietly returns worse results with no error anywhere — which is precisely the sort of failure that's hard to notice and hard to diagnose.

RAG: why the AI shouldn't answer from memory

Now the second half.

A language model like Claude has read a great deal of text and knows a lot of general things. It has never seen your case file. It doesn't know what your exhibits say, what the other side argued, or what the transcript records.

Ask it anyway and you hit the failure everyone has heard about: rather than saying "I don't know," it produces something plausible. Fluent, correctly formatted, and invented. This is what people mean by hallucination, and it's why AI has a poor reputation in legal work.

RAG — Retrieval-Augmented Generation — is the standard fix, and the name describes the order of operations:

1. Retrieval. Find the passages in your documents that actually bear on the question, using the arrow-and-angle method above.
2. Augmented. Put those passages in front of the model, along with your question.
3. Generation. The model writes an answer from the passages it was given, rather than from memory.

The shift is from "what do you know about this?" to "here are eleven passages from the record — what do they say about this?" The second question a model can answer well, because the material is in front of it.

The half people get wrong

The R matters more than the G.

If retrieval fails to surface the right passage, no amount of model quality rescues the answer. The model will faithfully summarise the wrong eleven passages and sound completely confident doing it. A better model produces a more articulate wrong answer.

This is why so much of Sound Suite is retrieval machinery rather than AI: chunking strategy, hybrid keyword-and-meaning search, and a reranker — a second, more careful model that re-scores the shortlist, because the fast first pass is fast partly by being approximate.

It's also why "what did the other side argue that I haven't answered?" is a hard question. Answering it requires retrieving something whose defining property is that you didn't think of it.

Citation: the part that makes it usable

Everything above produces an answer. This last piece is what makes the answer worth anything.

What a citation actually is

A citation is a promise: you can check this yourself. That's its entire function. It transfers a claim from "trust me" to "go look."

Which means the standard is specificity. "See the transcript" is not a citation in a five-thousand-page record — it's a gesture. "Volume 3, page 214, lines 8–19" is a citation, because it can be checked in ten seconds.

The same distinction decides whether an AI system is useful or dangerous. A summary with no pointers has to be taken on faith. A summary where every claim carries a page number can be audited — and given that the model will sometimes be wrong, audit is the only thing standing between you and filing something false.

Keeping the pointer attached

The engineering problem is that a citation is easy to lose. Every stage of the pipeline is a chance to drop it: a page becomes an image, an image becomes text, text becomes chunks, chunks become numbers.

Sound Suite carries the pointer through all of it. A chunk knows its document and its page. For transcripts it knows the line, because a reporter's record is organised around line numbers and a citation that can't reach them isn't precise enough to be useful.

So a search result isn't a passage. It's a passage plus where it came from — and that provenance survives all the way to the answer.

The subtle failure this prevents

There's a drift that happens in long conversations, and it isn't hallucination exactly.

The model reads a passage and summarises it accurately. Three exchanges later it refers to its own summary as though it were the document. By the time you're drafting, "the transcript says X" has become "X," and the page number fell off somewhere in the middle.

Nothing was invented. The claim just became unmoored. The defence is keeping retrieval citation-shaped, so that re-checking means following a pointer rather than reconstructing where something came from.

Putting it together

What actually happens when you ask a question in Claude Desktop:

1. You ask. In plain language, in the chat.
2. Claude calls a tool. Sound Suite is connected as an MCP server, so Claude can query your documents directly.
3. Your question becomes coordinates, using the same embedding model as your documents.
4. Nearest passages are found by angle — the cosine step.
5. A reranker re-scores the shortlist more carefully than the fast first pass could.
6. Passages return with their citations — document, page, and line where applicable.
7. Claude answers from those passages, quoting and citing rather than paraphrasing from memory.
8. You check. Click the citation, read the page, confirm it says what the answer claims.

Step 8 is not optional, and no part of the design pretends otherwise. The goal was never to remove you from the loop — it was to make checking cheap enough that you actually do it, every time, instead of spot-checking the claims that happen to look suspicious.

Where it still goes wrong

Worth stating plainly.

Retrieval can miss. If the relevant passage doesn't make the shortlist, the answer is built on an incomplete set and will not mention the gap. This is the most common failure and the hardest to notice.

A real citation can be the wrong citation. The system verifies that a passage exists and says what it says. It cannot judge whether that passage genuinely supports the proposition you're using it for. That still takes reading.

Meaning is approximated, not understood. Embeddings are a compression of meaning into a few thousand numbers. Usually excellent; occasionally a passage lands somewhere odd.

Chunk boundaries can split an argument. Overlap reduces this. It doesn't eliminate it.

Bad input stays bad. If a scanned exhibit OCR'd poorly, its text is garbled, and garbled text embeds to meaningless coordinates. Sound Suite scores each page for exactly this reason — so you can see which documents are genuinely searchable before relying on an answer drawn from them.

Why bother learning this

Because the difference between someone who gets good results and someone who concludes "AI doesn't work for legal" is usually not the tool. It's knowing what the tool is doing.

If you know retrieval can miss, you ask the same question three ways. If you know cosine ignores length, you aren't surprised when a short passage outranks a long one. If you know a citation is a pointer, you follow it.

None of this makes the machine trustworthy. It makes it checkable — which is the only kind of trustworthy that counts when your name is on the filing.

Next: how to actually work this way — the loop of asking, reporting, triaging and revising that turns all of the above into finished drafts.