In a document you authored, you cannot see where the splitter cuts — what follows for placing a span?

## Why the boundary is unobservable The author of an uploaded document controls every character in it and none of what happens next. Where a splitter cuts is decided by things on the other side of the upload: - **The configured size**, and whether it is measured in characters or tokens — the two disagree, and the disagreement grows with unusual text. - **The splitter's preferences**: some cut on a fixed count, some back off to the nearest paragraph or sentence break, some respect document structure. - **Overlap**, if any, which changes what a given region of text looks like in the index. - **The extractor's output**, which is the actual input to the splitter and is not the file. Layout linearisation, repeated headers, flattened tables, and text created by optical character recognition from a scan all shift offsets relative to what the author sees on the page. Re-ingesting the same file after any of these changes moves every cut point downstream of the change. So placement in a retrieval path is not aiming at a coordinate; it is aiming at a distribution. ## What follows: the redundancy calculus If a single offset has some probability of landing wholly inside one cut region, then independent-ish occurrences at spread-out offsets raise the chance at least one does. That is the whole of the reasoning, and it has three riders worth stating: 1. **Each occurrence must be short and complete on its own.** A long occurrence is more likely to be cut, and a fragment is inert. Brevity is what makes each copy a real chance rather than another near miss. 2. **The copies must be far apart.** Two occurrences a few lines apart are very likely to share a fate — either both inside one region or both around the same boundary. Spread is what makes them close to independent. 3. **Structure is a weak signal, not a control.** A splitter that respects paragraph or section breaks makes an authored break a more likely boundary, which lets an author reason about where cuts *tend* to fall without ever observing one. It shifts the distribution; it does not fix it. ## What redundancy costs This is the half a weak answer omits. - **Human surface.** A person skimming a contract will not read every clause, but repetition is the thing skim-reading is best at catching. The same paragraph recurring six times in a 200-page document reads wrong even to someone not looking for it. - **Scoring surface.** Any layer that scores text sees more of the same material, and repeated near-identical passages are exactly what near-duplicate detection is built to surface. More copies means more chances that one of them is the one that gets scored. - **Index pollution.** In a retrieval path, several near-identical chunks compete with each other for the same slots, and a result set full of duplicates is visible in a way one planted passage is not. - **Diminishing returns.** After a handful of well-spread copies the marginal copy adds little probability and the same increment of surface. The curve flattens; the cost does not. ## The direction that inverts In a summarising path, redundancy buys much less. One occurrence anywhere inside the surviving window is enough, and nothing cuts the middle of it. The remaining uncertainty there is not the cut point but the *edge* of the window, which moves with the rest of that turn's context — so a second occurrence far from the first still helps against a moving edge, but a dozen copies do not. ## What this looks like as a finding An engineer triaging a report should be able to read a spread of near-identical passages as what it is: an author compensating for an unobservable boundary. The absence of a single obvious placement is not evidence of sophistication; it is evidence that the person could not see the cut points either.