Why is page-one placement of an injected span in an uploaded document not a general rule?

## Three different things get called "the document" When somebody uploads a long file — a vendor contract, a filing, a scanned appendix — at least three artefacts exist afterwards, and they are not the same object: 1. **The bytes uploaded.** What a reviewer opens and scrolls, with pages, headers and layout. 2. **The text an extractor emitted from those bytes.** A different artefact: multi-column layout is linearised, headers and footers may be repeated or dropped, tables are flattened, a cover page may or may not appear first, and for a scan the text is *created* by optical character recognition rather than read out of the file. Nothing guarantees that "page one" of the upload is the first text in the extraction. 3. **What actually enters the model's context.** Either a chunk a retriever selected, or the slice of the extracted text that survived a truncation budget. The intuition behind "put it at the top so the model reads it first" is an intuition about artefact 1, read by a human, front to back. The model reads artefact 3. ## The retrieval path In a retrieval path the extracted text is cut into chunks, each chunk is embedded, and at query time a similarity search returns the nearest few. What reaches the model is a small set of passages, usually a few hundred to a couple of thousand tokens each, stripped of their neighbours. Ordinal position in the file has no role in that selection. A chunk from page 180 and a chunk from page 1 compete on the same footing: distance in a vector space between the query's embedding and the passage's. So an authored span sitting at the top of a 200-page file has no privileged status at all — it is in the index like everything else, and on any given question it is probably not returned. (Whether a planted passage *wins* selection is a separate matter, and not this question: assume selection happens, and ask whether the span is intact in what was handed over.) ## The summarising or fetch path A summarising pipeline over the same file has the opposite shape: it is trying to read everything, and it fails only because the file exceeds the budget. What it does then varies, and each variant implies a different answer to "where": - **Head-only truncation** — the first N tokens are kept, the tail is discarded. Here "the top" really does work. - **Head-and-tail** — an opening window and a closing window are kept and the middle is dropped. The top works; so does the very end; the middle is a dead zone. - **Map-then-reduce over sections** — every section is summarised separately and the summaries are merged. Nothing is dropped outright, but each section is read in isolation, and the merge step sees only summaries. Note what varies here: not the file, but the pipeline. The same upload, handed to two consumers, has two different answers for where a span has to sit. ## Why this is the first decision, not a detail Everything else about an injected span — what it claims, what it asks for, what it gets past — is conditional on the span being present in the context at all. Placement is the arrival question, and it is settled before any of the rest matters. An engineer who reasons about a span's wording without first asking which path will read the file has skipped the step that decides whether the experiment ran. ## Silence is not evidence The failure mode when placement is wrong is *nothing observable*. No refusal, no block, no error — the model summarises the contract normally, because the span was never in front of it. This matters because the same silence is produced by several very different causes: the span sat outside the truncation window; the chunk holding it was never selected; the extractor never emitted it; the model read it and ignored it; a screening layer removed it. A candidate who reads "nothing happened" as "it was filtered" has inverted the direction of the evidence. Absence of an effect proves only that no effect was observed. ## The practical consequence Because a corpus is usually read by more than one consumer — summarised once at upload, queried chunk-wise for months afterwards — an offset that satisfies one path may be irrelevant to the other. A single "where do you put it" answer that ignores the path is not a partial answer; it is a coin flip.