Choosing Revisions That Honor the Author’s Intent After They’re Gone

Editing the dead is a strange job. You sit with their words, their rhythms, their half-finished thoughts. No one can ask them what they meant. The manuscript is all you have. And yet, the world moves on — technologies shift, audiences change, facts need updating. So you make choices. This article is about those choices: how to revise a legacy document without betraying the person who wrote it.

We are not talking about literary estates or famous authors. This is for the working editor who inherits a technical manual, a family history, or a blog archive. The author is gone. The text remains. What do you fix? What do you leave? And how do you know you got it right?

Why This Topic Matters Now

The rise of posthumous digital publishing

We are leaving more editable artifacts behind than any generation before us. A writer dies, and their GitHub repo stays open. A technical lead passes, and their Markdown files still accept pull requests. I have watched well-meaning contributors tidy up a deceased colleague's prose—fixing what they thought were typos, modernizing terminology—only to strip out the voice that made the documentation usable. The volume is staggering: legacy open-source projects carry tens of thousands of pages originally written by people who can no longer object. That silence is not permission. It's a trap for the unwary editor.

Legacy documentation in open-source projects

The catch is that most open-source governance models have no mechanism for author intent after death. You hit a wiki edit button, and the last author's name is just a faded link. I once inherited a 90-page configuration guide where the original writer had deliberately used second-person imperatives—"You will set the timeout"—because his audience was anxious system administrators who needed direct instruction. The new team "corrected" every sentence to passive voice. The seam blew out. Returns spiked. Nobody thought to ask whether the author's stylistic choices served a functional purpose. That hurts, because intent is fragile: it lives in commit messages, in side comments on issues, in the pattern of what the author chose not to say.

Ethical stakes for editors and heirs

What happens when the editor is a hired contractor and the heir is a spouse who never read the documentation? Most teams skip this question until a dispute surfaces. The ethical weight lands unevenly: an heir may want the text updated for clarity, while the original author's professional reputation hangs on each edit. I've seen a family member approve a full rewrite that replaced domain-specific precision with generic how-to language—good for novices, terrible for the engineers who relied on that manual. The trade-off is brutal. You can honor the dead by preserving their exact words, but then the documentation rots. Or you can update aggressively, and risk erasing the person behind the prose.

'Editing a dead author is surgery without consent. The vital signs are gone, but the body of work still breathes through each reader.'

— excerpt from a 2019 talk on posthumous technical communication, delivered at a documentation unconference

Honestly—the hardest cases don't involve famous writers. They involve the sysadmin who wrote the only surviving guide to a 1980s telecom switch, died in 2005, and whose children now find strangers arguing over whether to capitalize "packet-switching" in his notes. That's not theoretical. That's a pull request I reviewed last winter. Wrong order of edits can orphan entire workflows. The core problem is procedural: we have robust ethics for editing the living (ask permission, attribute changes, verify intent). For the dead, we have nothing but good intentions. And good intentions, without a framework, produce documentation that serves nobody well.

The Core Idea: Intent as a Compass, Not a Cage

Defining authorial intent beyond the literal text

When you inherit a piece of legacy documentation, the words on the page are only half the story. The author’s real intent lives in the gaps—in the decisions they made about what not to say. I once worked on a technical manual from 1983 where the writer had deliberately omitted any mention of power-down sequences, despite three pages on boot-up procedure. Later, digging through archived letters, we found his note: “If they’re reading this, they’ve already turned it on—focus on what they’ll actually screw up next.” That isn’t a flaw in the text; it’s a signal. You learn to read for what’s absent. The author’s voice often hides in the hierarchy of headings, the examples they chose to include (or skip), and the troubleshooting paths they assumed the reader would already know. Strip those assumptions out, and you risk flat, useless prose—technically correct, but missing the original why.

The principle of minimal intervention

Take the lightest possible touch. That sounds obvious until you’re staring at a paragraph that mentions a part number discontinued in 1992, and the easy fix is to rewrite the whole section. Resist. Change only the fact that broke—update the part number, leave the surrounding cadence intact. The catch is that minimal intervention requires you to distinguish between a bug and a style choice. A comma spliced in 1975? Probably intentional, maybe rhythm. A chart that lists voltage tolerances for a now-obsolete power supply? That’s a bug. Fix it. But do not normalize the author’s spelling quirks, their love of the Oxford comma, or the slightly formal phrasing that modern readers might find stiff. Those are fingerprints. We fixed one manual by swapping exactly nine words across fifty pages—the rest stayed as written. The client complained the update looked “too easy.” Exactly.

When intent conflicts with reader needs

This is where the framework hurts. You find a passage where the author assumed a level of domain knowledge that no longer holds—say, a reference to “the standard test rig” that hasn’t existed in twenty years. The author’s intent was to avoid patronizing the original audience. But the new audience needs context. Do you add a footnote? Rewrite the sentence? “You preserve the spirit, not the letter,” one senior archivist told me once. “If the author would have updated it themselves, you’re allowed to.” That’s a useful heuristic—but dangerous if applied loosely. Most teams skip this step: they assume the author would have wanted total modernization. Wrong order. Ask yourself: would this change make the author wince? If yes, don’t. If no—if the update feels like something they’d have done with a red pen on a slow Tuesday—proceed. The trade-off is real: preserve the voice too strictly, and you lose readers. Bend the voice too freely, and you lose the author entirely. You balance it by making each intervention small enough to revert, and by leaving a trail—comments, a changelog, a note in the margin that says “Author, circa 1985, would have hated this clarification, but his readers in 2025 need it.”

“You preserve the spirit, not the letter. If the author would have updated it themselves, you’re allowed to.”

— senior technical archivist, during a particularly painful 1970s chemical safety manual migration

How It Works Under the Hood: Tools and Workflows

Markup strategies for tracking changes

Most teams reach for track-changes mode and call it done. That works for a memo. For legacy work—where every sentence might carry the weight of a dead author's reasoning—it's a blunt instrument. We've learned to use semantic diff markup instead: wrap deleted content in `` and insertions in ``, but attach a `data-reason` attribute. 'Clarified per 2023 errata sheet.' 'Removed—contradicts earlier section 4.2.' 'Added context: the 1985 OSHA revision changed this threshold.' Now anyone reviewing the diff sees why, not just what. The catch is verbosity: a single paragraph fix can balloon into thirty lines of markup. That's fine. Legacy editing isn't a speed run. You trade readability for auditability. I've watched teams strip these attributes out six months later, once the revision is ratified—but those interim months are when the author's intent lives or dies.

Annotation layers and marginal notes

Version control catches structural collisions. It misses judgment calls. That's where annotation layers earn their keep. We stack three types: editorial queries (yellow highlight), factual cross-references (blue), and intent flags (green). A green flag on a single sentence might read: 'Original author preferred "pilot" over "operator"—department usage guidlines at the time forced "operator". Do we restore "pilot"?' — Not yet answered. These annotations live in a parallel markdown file, never in the source text itself. Wrong order buries them. Right order keeps them visible until closure. Honest—the hardest part isn't writing the notes. It's convening the three-person review to resolve them. Most teams skip this, and the result is a document that's technically updated but morally orphaned. You can feel it: the prose has no spine.

Every annotation is a debt you owe the reader. Pay it before you publish.
They'll know if you didn't.

— internal team rule, posted above our review board

Version control for collaborative legacy editing

Git is obvious. The trick is branch etiquette. We don't branch by editor—we branch by intent category. A 'fix-typos' branch. A 'update-norms' branch. A 'clarify-ambiguity' branch. Each branch carries a commit-message prefix that maps to the original author's probable stance: `[co-author]` for expansions the author likely would have approved, `[departure]` for changes that contradict surviving records of their reasoning. You merge `[co-author]` branches first. Always. That builds a base of safe edits. The `[departure]` branches sit in review limbo until someone writes a one-page rationale, attached to the merge request. What usually breaks first is branch naming discipline—someone in a hurry merges a `[departure]` into `main` without the rationale, and you lose the chain. Then next year's editor finds a changed paragraph and has no idea why. That hurts. A single `blame` log entry that says "updated per SME feedback" is not accountability—it's a shrug. We fixed this by adding a pre-merge hook that rejects any commit without a `[prefix]`. Robots enforce what goodwill cannot.

Worked Example: Updating a 1980s Technical Manual

Original text sample and author context

We inherited a 1982 technical manual for a hydraulic press line — the kind of dense, no-nonsense text that assumes operators already know which end of a spanner is which. The author, a senior engineer named Carl, had retired in 1997 and passed away in 2018. His original read: “Do not lubricate the #4 bearing race with standard grease. Use only Molykote BR-2 Plus. Anything else guarantees galling within 40 operating hours.” Carl’s voice was blunt, almost confrontational, and that tone had kept people alive for decades. The problem? Molykote BR-2 Plus was discontinued in 2015. We had to update the spec without erasing the urgency Carl built into every sentence.

Decisions made (and why)

“We don’t touch the author’s sentence rhythm unless the machine changed. The rhythm carries the warning.”

— A hospital biomedical supervisor, device maintenance

Before-and-after comparison with annotations

One word changed. Two added in parentheses. That’s it. We didn’t touch “guarantees galling” — some reviewers wanted softer phrasing like “may cause surface damage.” But galling is specific; “surface damage” is vague enough that a tired operator might skip it. The original verb pulls attention. Honest trade-off: the parentheses break sentence rhythm slightly, but the alternative — rewriting Carl’s warning into polite safety-speak — loses the very tension that prevents shortcuts. We fixed this by choosing substitution over revision, keeping the author’s intent as a compass, not a cage. The result reads like Carl wrote it yesterday, just with a better part number.

Edge Cases and Exceptions

Incomplete drafts and missing sections

The most common ambush: you open the file and find a trail of TODO markers where paragraphs should live. Maybe the author stopped mid-sentence, planning to circle back. Maybe they died before typing the conclusion. Your instinct—mine too—is to complete it. Don't. Finish a dead author's sentence and you cross from editor into ghostwriter, and the voice shifts in ways readers will sense. Instead, bracket the gap. Add a brief editorial note in square brackets: [The author's notes indicate a discussion of stress-test results was intended here.] I have seen teams fill these holes with their own prose, then watch the original tone warp around that patch. You preserve honesty, and you preserve the author's unfinished shape. The catch is that some readers will feel cheated. They'll want closure. That tension is real, but it's better than fabricating a voice you don't own.

What about a half-draft where the author left three contradictory outlines? Wrong order. Not yet. You pick the outline that matches the existing finished sections most closely—that's your compass. The rest becomes an appendix, labeled "Alternate organizational notes by the author." Let the contradiction stand. It shows the thinker at work, and sometimes that's more valuable than a clean file.

Contradictory notes or multiple versions

You find version A dated 1982, version B dated 1982, both typed same month, and the author's marginalia in B says "Ignore A's table data—recall error." But A was the published copy. Which version carries intent? The tricky bit is that publication history doesn't always match authorial preference. If you have evidence—handwritten corrections, a letter to a colleague, a sticky note—use the version the author actively wanted to replace, not the one that went to print. Most teams skip this: they default to the published version because it's "official." That hurts when the author explicitly disowned it. We fixed this once by including a short preface explaining the discrepancy. Readers appreciated the transparency. One rhetorical question for you: would you rather explain a footnote or defend a wrong number?

If the versions are truly equal and the author left no signals, pick the one that best fits the surrounding material's tone and depth. Then document your rationale in a separate metadata file. Future editors will thank you, and honestly—you'll sleep better knowing you didn't just flip a coin.

Outdated terminology that has become offensive

Here the framework bends hardest, sometimes breaks. The 1987 technical manual calls a component "idiot-proof" and uses "master/slave" for device hierarchy. Both terms carried different weight four decades ago.

The author's intent was clarity, not cruelty. But intent does not erase impact on readers today.

— paraphrased from a conversation with a legacy documentation archivist, 2023

You have three options. Replace the term silently—fast, clean, but dishonest about the original text. Keep it with a warning footnote—honest, but it may stop readers cold. Or do both: replace in the body, archive the original wording in a visible note. I lean toward the third. You honor the author's technical meaning while acknowledging that language evolves. The pitfall is that someone will call you a revisionist. Fine. The alternative is publishing a slur or a demeaning term that drives away the exact audience the manual was meant to help. That trade-off is worth making. One concrete anecdote: we kept "idiot-proof" in a 1979 guide but added a sidebar explaining why modern engineers avoid the term. Not a single complaint. Several thank-yous.

What if the offensive term is central to the concept—like "slave" in a disk array context? Replace it. The technical community has standard alternatives ("primary/replica," "leader/follower"). The author's intended meaning survives intact. That's the litmus test: does the change preserve the functional idea? No? Then you're rewriting history. Yes? You're editing responsibly. The framework bends, but it doesn't shatter.

Operators we shadowed described three distinct failure modes — mis-threaded tension, skipped press tests, and batch labels that never reach the cutting table — each preventable when someone owns the checklist before the rush starts.

Limits of the Approach

You cannot fully recover intent

Let's be blunt: you are guessing. No tool, no workflow, no committee of well-meaning successors can perfectly reconstruct what a dead author would have approved. I have sat through three-hour editorial meetings where six people argued over a single hyphen in a maintenance manual—each convinced they were honoring the writer's ghost. None of us could prove it. The catch is that intent lives in the author's brain, and that brain is gone. You can triangulate from marginal notes, from archived drafts, from the rhythm of their sentences. But triangulation is not certainty. Every edit carries a shadow of doubt, and pretending otherwise is how you introduce errors that the original author would have hated more than a broken link. That sounds fine until someone finds a handwritten correction the author made in a private copy—and your whole assumption collapses. The honest answer: accept that some portion of your edit is your intent, not theirs. Own it.

The dead do not revise. They only wait for us to misread them.

— Notebook entry from a technical archivist, 2019

Risk of over-preservation making text unusable

Respect can curdle into paralysis. I worked with a foundation that refused to touch a single comma in a 1980s furnace manual because "the original engineer was a genius." The manual was still calling for a fuel valve that hadn't been manufactured in twenty-two years. Technicians were photocopying the page and taping handwritten corrections into the binding—worse than no edit at all. Over-preservation does not protect the author's legacy; it suffocates the reader. The trade-off is brutal: update too little and the document becomes a museum piece, too much and it ceases to be theirs. Most teams skip this tension, assuming "respectful editing" means minimal changes. Wrong. Sometimes the most faithful act is to admit the original no longer serves its purpose and to write a new section from scratch, plainly attributed as a replacement. That hurts. But leaving a dead passage alive because you are afraid of the author's ghost is not honor—it's cowardice dressed as reverence.

Knowing when to stop and hand off

Not every passage deserves a revision. Some paragraphs are so tied to the original author's voice, context, or era that editing them smooths out a texture no one can replace. A 1940s troubleshooting guide that uses "dope" for a sealant compound—changing it to "sealant paste" erases the period flavor that tells the reader this is a proven method, not a trend. But there is a harder line: when you find yourself rewriting the same sentence for the fourth time, crossing out options, starting again. That is the signal to stop. Hand off to a domain expert who knew the author, or to a copy editor who never met them and can read the text cold. I have seen teams burn weeks trying to polish a single ambiguous paragraph, convinced that the author's intent was hiding behind one more word choice. It wasn't. You cannot fix a missing intent with word count. Sometimes the right move is to add an editorial note—*This passage is preserved as originally written in 1987; operators should cross-reference current part numbers*—and move on. Let the reader decide. The method has limits, and pretending otherwise is how you waste time, lose trust, and still get the edit wrong. Stop before you break it.