Overlap and boundaries

Every split risks a boundary wound: the fact you need lives half in one chunk, half in the next, and neither half retrieves well alone. Two defenses exist — one popular and overrated, one boring and underrated.

Overlap: the popular one

Overlap repeats the last ~10–20% of each chunk at the start of the next, so a sentence straddling the cut exists whole in at least one chunk. It's cheap insurance for fixed-size chunking, where cuts are arbitrary. But be clear about the costs: more chunks to store, duplicated text that can retrieve twice (crowding out a genuinely different second source from your top-k), and near-duplicate neighbors that confuse evaluation. And here's the underrated point — good structure-aware boundaries mostly remove the need. A cut at a heading doesn't bisect a thought; overlapping across it just glues unrelated sections together.

Boundary rules: the underrated one

• Never separate a heading from its first paragraph — the heading is the paragraph's context ('Holiday returns' above 'the window extends to January 31' is the difference between a useful and a useless chunk).
• Keep list items with their lead-in sentence. A retrieved chunk starting at bullet 3 of 'You must provide:' is noise.
• Never split tables. Half a table is worse than no table. If it exceeds max size, the table is the chunk.
• Attach trailing qualifiers. Sentences beginning 'However', 'Except', 'Note:' modify what precedes them — a chunk ending right before an exception is a wrong-answer factory: it retrieves confidently and states the rule without its exception.

That last rule deserves its own paragraph, because it's the boundary bug that produces harmful rather than merely weak retrieval: the model answers 'returns are accepted within 30 days' — fully grounded, citation verifying! — while the very next sentence in the source said 'except final-sale items'. No amount of prompt engineering downstream fixes a chunk that ends one sentence too early. Chunking is where grounding integrity starts.