The Author's Seams: Cut Where the Document Already Bends

Ask a tailor to cut a garment and they'll do something that looks like cheating: they follow the seams that are already there. The fabric tells them where it wants to come apart. Fighting the seams — cutting diagonally across a woven pattern because a ruler said 30 centimeters — gets you frayed edges and ruined cloth.

Documents have seams too. Headings. Sections. Paragraphs. Bullet lists. Every one of them is a decision the author already made about where one idea ends and another begins — hundreds of tiny editorial cuts, performed by the person who understood the material best, embedded in the document for free.

And the default chunking pipeline ignores every single one, slicing every 500 tokens like a shredder that can't see. Parts 1 and 2 diagnosed what bad cuts do. Today is the single highest-leverage fix in this series, and the least clever: cut where the author cut.

Headings are instructions

Reframe what a heading is. To a reader, it's navigation. To a chunker, it's an instruction: "new idea starts here — everything until the next heading belongs together."

A structure-aware cutter treats those instructions as law. Section boundaries become chunk boundaries. Paragraphs stay whole. A bulleted list — one idea expressed as seven fragments — travels as one piece, because splitting a list mid-bullet manufactures the purest confetti there is: items with no stem, "the following exceptions apply" with no exceptions.

The improvement over fixed-size shredding isn't marginal; it attacks all three Missing Pages from Part 1 at once. Split answers stop happening because cuts land between ideas, not through them. Buried answers shrink because sections are naturally about one thing — the author saw to it. And the third failure, the answer that lost its name, gets the most elegant fix of all.

Carry the labels: the self-locating chunk

The parent series planted this move in one paragraph; it deserves its full argument, because pound for pound it's the most valuable trick in the workshop.

When you cut at a heading, don't just keep the text below it — stamp the chunk with its full lineage: Ops Handbook → Incident Response → Escalation Policy: followed by the content. Now the chunk that says "notify the incident commander within 15 minutes" carries its own name. It knows what it is.

I call this the self-locating chunk, and it pays twice. It pays at search time: the words "escalation policy" now literally appear in the chunk, so both keyword search and the map of meaning (whose address sharpens dramatically when the topic is stated rather than implied — The Map of Meaning series explains exactly why) file it correctly. And it pays at answer time: the model receives a passage that announces its own context, instead of an orphan paragraph it must guess about. One string-concatenation at ingestion; findability and answer quality both improve. There is no better exchange rate anywhere in RAG.

The hierarchy bonus

Structure-aware cutting has a further gift: documents aren't flat, and their seams nest. A handbook contains chapters, chapters contain sections, sections contain rules. Respecting the hierarchy lets you cut at the right level per use — fine-grained chunks for precise retrieval, each stamped with the coarse-grained path that locates it. Some teams go further and retrieve small-but-precise chunks, then hand the model the surrounding section for context — small cards to find, bigger cards to read. That refinement has a dozen fancy names in the literature. The load-bearing idea under all of them is today's: the author's structure is information, and the shredder throws it away.

The catch

Every honest article in this series has one, and today's is big enough to be next week's episode: structure-aware cutting requires structure the cutter can see. Markdown, HTML, and wiki pages hand you their seams — headings are labeled, lists are marked, the tailor's work is easy. But an enormous share of real corporate knowledge lives in formats where the structure is visual, not marked: PDFs whose "headings" are just bold text at a slightly larger size, scanned documents, exports where the layout got flattened into a stream of positioned characters. The seams exist — a human sees them instantly — but nothing in the file says they're seams.

Which is where chunking goes from craft to combat. The documents start fighting back.

The one line to remember

Every heading is the author telling you where to cut — and a chunk stamped with its own lineage is findable by name, not just by luck.

Next — Part 4: "The Decapitated Table." PDFs, tables, and the documents that fight back — including the failure that turns sixty rows of numbers into sixty rows of amnesia.