Dead-Paragraph Elimination: What the Reader Loses. A beautiful paragraph still needs to contribute something the reader can use.

A paragraph can read beautifully and contribute nothing to the argument around it. My original build note about dead-paragraph elimination reported fourteen cuts from a draft of the People Product Process essay. One was a metaphor about cathedral architecture that I'd been particularly proud of. The note records a tighter surviving draft that made the same argument without it.

The cathedral paragraph gives the proposed editing pass a concrete test. What did the reader lose when it disappeared? A sentence's elegance can be worth keeping, but attachment to the sentence doesn't answer that question.

I borrowed the idea from compiler optimisation. Represent a draft as connected parts, record what each part contributes, then examine the parts whose contribution goes unused. Applying that idea to prose requires a definition of "used" that includes the reader. Otherwise, a pass meant to remove padding can remove the explanation that made the argument understandable.

My content-compiler work started with a problem in AI writing. A model could produce a useful passage, then drift across a longer document. Asking for another complete draft also meant changing passages that were already doing their job. I described a different approach in my compiler account: keep the parts individually addressable so a change can target one part. LLVM's intermediate representation and the browser's document tree were the models for it.

An intermediate representation, or IR, is the structured form between the input and the finished output. The original note applies that idea to paragraphs. A paragraph becomes a node with claims it needs and claims it contributes. Analysis can then ask how that paragraph relates to the rest of the draft before anyone changes its sentences.

LLVM's dead-code elimination supplied the comparison: examine whether a computation's result is used. The editorial version asks whether the paragraph contributes something the piece needs. That's a design question with an editorial judgment inside it. Borrowing a compiler's organisation doesn't make prose equivalent to executable code, and it doesn't establish that a particular automated pass has shipped.

The original note describes paragraph inputs as claims the paragraph depends on, and outputs as claims that another paragraph or the conclusion uses. Those relationships give an editor something more specific to inspect than whether a passage sounds good.

Take this illustrative argument about diagnosing a customer's problem. It starts by distinguishing a customer's problem from the product being sold. It then describes the future the customer wants. A later passage explains the changes needed to get from the problem to that future.

The transformation passage depends on both earlier passages. Remove the description of the problem and the reader has no basis for judging whether the proposed change addresses it. Remove the desired future and the same change has no stated destination. A paragraph that repeats the product's features may contribute nothing to either dependency, even when every sentence is accurate.

The inherited diagram depicts that dependency-based approach. Treat its disconnected nodes as candidates for review, because a missing connection may also mean the map is incomplete.

The useful record is what a paragraph adds and where that contribution is needed. A list of paragraph topics won't tell an editor whether the reasoning survives a cut.

A literal "nothing downstream reads this" rule would put the conclusion at risk. A conclusion may be the thing the whole essay exists to establish, even though no later paragraph depends on it. The editorial map needs to identify the understanding or decision the piece promises its reader, then trace the support for that outcome.

Evidence needs attention too. A case can support a claim without adding a new claim. Deleting the case might leave every assertion intact while removing the reader's reason to believe any of them. An explanation can do a different job again: it can make a relationship understandable to someone who hasn't worked with the subject before.

I'd record a paragraph's contribution beyond its new assertions. Support for a claim, a necessary qualification and an explanation of a difficult step all need to appear in the analysis. Their absence from a graph is a reason to inspect the graph before cutting the prose.

Repetition also needs a purpose test. A second paragraph that says the same thing in different words may be redundant. A return to an earlier claim after a difficult explanation may help the reader connect the explanation to the argument. The editor has to inspect what changed between those appearances.

The cathedral metaphor belongs under that same test. Its removal is justified only if the surviving passage still does the teaching work it was meant to do. "I like this paragraph" and "the reader needs this paragraph" are different claims, and each needs its own reason.

Pydantic-as-IR is the architecture described in the original note. The note describes parsing an existing draft into nodes, and also describes a graph structured before prose exists. Those are different starting points, so a pass needs to make clear which representation it's analysing. My recorded engineering account explains Pydantic's appeal: defining a data model forces me to think about what passes through the system and gives me one place to refine that structure. A paragraph's prose can sit alongside a record of its claims and dependencies, so a pass can inspect the relationships without replacing the whole document.

That structure still records an interpretation. Someone has to identify the claim, decide what supports it and notice which qualification changes its meaning. Putting those judgments into typed records makes them inspectable. It doesn't make them true.

I'd keep the source passage attached to any proposed deletion, together with the reason for the cut. The original note says the cathedral paragraph was retained as a source comment. A cut should remain recoverable when a later read reveals that the paragraph carried something the analysis missed.

The same separation limits the size of an edit. A pass can propose removing one paragraph while leaving neighbouring prose alone. The reader then compares the surviving argument with the original, looking specifically for lost support, missing context or a claim that has become broader. A shorter draft is an observable result. A better draft still requires that comparison.

The original note names common-subexpression elimination as the next pass to borrow. Its proposed editorial equivalent finds paragraphs that make the same claim in different sentences, then keeps the stronger treatment. That's a different question from whether a paragraph contributes anything at all.

The stronger treatment needs a definition too. A concise paragraph may state the claim clearly while another provides the evidence. Combining their useful parts could preserve more value than choosing one and deleting the other. A pair that looks repetitive may also apply the claim under different conditions. Dropping one condition would change the meaning of the surviving argument.

The practical starting point is a manual pass through an actual draft. Write down what the reader should understand or be able to decide at the end. Then give each paragraph a short account of what it contributes and what it depends on. Mark passages whose contribution is already supplied elsewhere, or whose removal appears to leave that reader outcome intact.

Try a candidate cut without rewriting the surrounding section. Read the result for the specific contribution that was supposedly unnecessary, then check the source passage for a lost condition or piece of evidence. Keep the reason beside the recoverable original.

That's the test I'd apply to the cathedral paragraph. Whether a particular paragraph should stay depends on what the reader can still understand after it goes.