The manual is spiral-bound, oil-stained, its cover long detached. I found it in a repair shop in Gothenburg that had been shuttered since 2003, the inventory sold off by the kilogram. It’s the service documentation for a Fujitsu dot-matrix printer—the kind that hammered tractor-fed paper with a sound like a sewing machine falling down stairs. What stopped me wasn’t the exploded-view diagrams or the diagnostic flowcharts. It was the margins.
Every page had been written on. Not by the original technical writer, but by the technicians who used the manual over two decades. In blue ballpoint, in pencil, in a spidery fountain-pen hand that suggested someone older, trained on drafting tables. Adjust platen gap to 0.45mm when humidity >70%. Replace ribbon before it looks worn—optical density drops 15% before visible fading. Error 23 on this batch: check capacitor C47 first, factory used wrong dielectric. One annotation, in red ink and underlined twice: DO NOT follow page 4-12 procedure on units shipped after Nov 1987. Head carriage geometry changed. Use supplement 3 instead.
This was a text that had been maintained. Not updated through a formal revision process—there was no version control, no change log, no sign-off from engineering. It was maintained through situated, tacit knowledge, inscribed directly onto the artifact by the people who discovered that the artifact’s assumptions were wrong. The manual had become a palimpsest of field experience, each layer correcting the layer before it for conditions the original authors never anticipated: humidity, component substitutions, undocumented production changes, the slow drift of mechanical wear.
I’ve been thinking about that manual for weeks now, because I’ve been watching colleagues use AI writing tools—for documentation, for specifications, for the kind of prose that’s supposed to guide action—and noticing something absent. The text arrives clean. It arrives confident. It arrives without margins.
The Clean Text Problem
Modern language models train on text stripped of its context. The corpus is vast, but vast in a particular way: it favors the published, the finalized, the text already separated from the conditions of its production. A Wikipedia article doesn’t carry annotations from the editors who fought over a disputed claim. A technical specification on a company’s documentation site doesn’t show the three rounds of review where a senior engineer argued that the tolerance was too tight for the supplier’s actual capability. A user manual doesn’t include the marginalia from the support team who discovered that step 7 only works if the device has been powered on for at least 90 seconds.
What gets preserved is the output, not the maintenance. The text ships, and then it’s frozen. If it’s wrong, it stays wrong until someone ships a replacement. There is no mechanism for the kind of annotation that kept that Fujitsu printer alive through fifteen years of undocumented production changes.
This matters because writing that guides action—engineering specifications, test procedures, assembly instructions, field service documentation—is never finished. It’s only ever current. The gap between what the text assumes and what the world actually presents grows over time, and the only thing that closes that gap is someone noticing, someone writing in the margin, someone saying this doesn’t work under these conditions, here’s what does.
When we generate text with AI, we get the finished surface without the substrate that would allow it to be corrected. We get the manual without the margins.
What the Annotations Actually Did
Let me be precise about what those technician annotations accomplished, because it’s easy to romanticize them as “tacit knowledge” and move on. They did four specific things:
First, they localized the text. The original manual was written for a generic printer in a generic environment. The annotations made it specific to a particular batch of printers, a particular climate, a particular set of component substitutions that happened somewhere in the supply chain. “Adjust platen gap to 0.45mm when humidity >70%” is not a universal instruction. It’s an instruction for Gothenburg, or maybe for coastal installations generally, where the paper absorbed moisture and swelled just enough to change the print head clearance.
Second, they temporalized the text. “DO NOT follow page 4-12 procedure on units shipped after Nov 1987” is a version constraint. The manual had become a document with an internal chronology, where different sections applied to different eras of the same product. This is version control without the infrastructure of version control—just a human being who knew that the product had changed and wrote it down where the next human being would see it.
Third, they corrected the model of degradation. The original manual assumed certain failure modes and certain maintenance intervals. The annotations corrected those assumptions based on observed behavior. “Replace ribbon before it looks worn—optical density drops 15% before visible fading” is a correction to the visual inspection criterion. The technician had measured what the eye couldn’t see and wrote the measurement into the procedure.
Fourth, they preserved the reasoning. The annotations didn’t just say what to do differently; they often said why. “Factory used wrong dielectric” explains why C47 fails first on a particular batch. That explanation matters because it tells the next technician what else to check—if the factory substituted one capacitor, they might have substituted others. The annotation carries diagnostic logic, not just corrective action.
None of these four functions are present in AI-generated text by default. The model produces text that is generic, atemporal, assumes a fixed product and a fixed environment, and rarely explains its reasoning in a way that would allow someone to challenge it under different conditions.
Writing for Maintenance, Not Just for Shipping
The distinction I’m circling is between a text that ships and a text that can be serviced. Most of our writing practices—and nearly all of our writing tools—are optimized for shipping. We want the document done, approved, published, handed off. The measure of quality is how few revisions it needs before it can be declared complete.
But some texts need to be maintainable. They need to accept correction without requiring replacement. They need to carry their own revision history in a way that’s visible to the next reader. They need to be written with the assumption that they will be wrong someday, and that the person who discovers the wrongness needs a place to record what they found.
This is not how we train people to write. The Purdue OWL’s creative writing resources, for instance, teach writing as a craft of iteration and revision—but the iteration happens before publication. The workshop model assumes a text that improves through drafts until it reaches a final form. What it doesn’t teach is how to write a text that expects to be revised by its readers, in the field, under conditions the author cannot predict. The pedagogy is about producing a finished artifact, not a maintainable system.
And yet, for the kinds of documents that engineers produce—specifications, test plans, failure analysis reports, field service bulletins—maintainability is more important than initial correctness. A specification that is 90% correct but can be annotated by the people who discover the other 10% is more valuable than a specification that is 95% correct but frozen. The margin is the feature.
What AI Writing Tools Don’t Know About Time
Language models are trained on snapshots. The training data represents a particular moment—or rather, a blurred composite of many moments, none of which are timestamped in a way the model can reason about. The model doesn’t know that a certain technical fact was true until 2019 and then became false. It doesn’t know that a procedure was valid for hardware revision A but not revision B. It doesn’t know that an instruction assumes a supply chain that existed in 2021 and collapsed in 2023.
This temporal blindness is not a minor limitation. It’s a structural incapacity to produce the kind of text that can survive contact with a changing world. When an engineer writes a specification, they are—if they’re good—writing with an awareness of what might change. They leave hooks for future revision. They note assumptions explicitly so that someone can check them later. They write in a way that invites annotation.
AI-generated text doesn’t do this. It writes as if the world is static, as if the product will never change, as if the supply chain will always have the specified component, as if the environment will always match the design assumptions. It writes for a photograph of reality, not for reality’s ongoing film.
The Authors Guild, in its AI best practices for authors, recommends that writers who use AI tools “annotate and document the extent of AI assistance” and maintain transparency about what parts of a text were generated. This is a form of maintenance thinking applied to prose itself. The annotation—”this section was AI-generated, based on prompt X, reviewed by human Y for accuracy on date Z”—creates the margin that future readers need. It tells them where to direct their skepticism. It tells them what might need updating when the underlying facts change. It transforms a shipped text into a serviceable one.
But this practice is rare, and it’s not built into the tools. The AI writing interfaces I’ve seen are designed for generation, not for annotation. They produce clean text in a clean window, and if you want to add metadata about provenance, assumptions, or revision history, you do it somewhere else—in a separate document, in a commit message, in your head. The margin has been designed out of the system.
The Annotation Layer as Infrastructure
What would it mean to build the annotation layer back in? Not as a feature request for a specific tool, but as a practice—a way of writing that assumes the text will need maintenance and builds the substrate for that maintenance from the start.
I can see at least three elements:
Assumption tagging. Every claim or instruction that rests on a contingent fact—a component availability, an environmental condition, a software version, a regulatory requirement—should be tagged with that contingency. Not buried in a front-matter section that no one reads, but adjacent to the claim itself, in a form that invites correction. “This procedure assumes ambient temperature 15–30°C. If operating outside this range, adjust dwell time per the correction factor table—or annotate here with your measured correction.”
Provenance marking. Text that comes from a language model should carry that information visibly, not as a shameful admission but as a maintenance instruction. “This section generated by [tool/model/date], reviewed by [person/date] against [source/standard].” The reader now knows that the text has a particular kind of origin, and that origin has particular failure modes—hallucination, outdated training data, lack of domain-specific context—that they should be alert to.
Correction channels. A text that can be serviced needs a defined way for corrections to enter it. The Fujitsu manual had the physical margin. A digital document might have a parallel comment layer, or a structured errata mechanism, or a convention for inline annotations that are visually distinct from the original text. The channel matters less than the expectation: that the text will be corrected, that corrections are expected and valued, that the person who finds an error has a responsibility to mark it for the next person.
None of this is technically difficult. It’s culturally difficult. It requires treating a document not as a finished product but as a living system—one that degrades over time, one that needs maintenance, one whose maintainers need tools and permissions to do their work.
The Long Now of Prose
There’s a deeper question here about what we think writing is for. If writing is for communication in the present—if the document only needs to be true at the moment it’s read by its first audience—then shipping is sufficient. Write it, check it, send it, move on.
But some writing is for the long now. It’s for the technician who will service the device in seven years, after the original engineering team has dispersed. It’s for the regulator who will audit the process in a decade, when the standards have changed. It’s for the user who will encounter the product in a context the designers never imagined, and who needs to understand not just what the product does but what it assumes.
This kind of writing needs to carry its own maintenance manual. It needs to tell the future reader where it came from, what it depends on, what it doesn’t know, and how to fix it when it’s wrong. The annotations in that Fujitsu manual weren’t vandalism or clutter. They were the maintenance manual for the manual itself—the meta-layer that kept the text true as the world changed around it.
When I look at how AI writing tools are being used in engineering contexts—for generating test procedures, for drafting specifications, for producing the documentation that will guide physical work on physical objects—I see a lot of clean text. I don’t see a lot of margins. I don’t see assumption tags or provenance marks or correction channels. I see text that has shipped, and I wonder who will service it.
Consider the contrast with an how Unsloppy AI Novel Writing App fits the writing workflow that structures long-form fiction generation. Fiction, of all genres, is the domain where the “finished” text is most sacred—where the author’s final draft is the artifact that goes to print. And yet even fiction has a maintenance history: drafts, editorial correspondence, the author’s own annotations on galleys. The difference is that in fiction, the maintenance is traditionally hidden from the reader. In engineering documentation, hiding the maintenance is a liability. The reader needs to see the repair history to trust the text. A tool that generates clean narrative without exposing its own revision layers inadvertently models the very problem we need to solve: it ships a surface with no visible annotation layer, no built-in way for the next reader to see what was assumed, what was changed, or what might break.
What the Technician Knew
The person who wrote “Error 23 on this batch: check capacitor C47 first” knew something that the original manual’s authors didn’t. They knew that the text was wrong for their specific situation, and they knew that the next person to encounter the same situation would need their correction. They also knew—and this is the part I keep coming back to—that they might be the next person. The annotation was a note to their future self as much as to a colleague.
This is the shift in mindset that maintenance writing requires: the author imagines themselves as a future reader, encountering the text under changed conditions, needing to know what to trust and what to override. It’s a form of temporal empathy. It’s writing with the awareness that you will forget what you know now, and that the text needs to remind you—or needs to have a place where your future self can add the reminder.
AI writing tools, as they currently exist, have no model of this. They generate text from a static snapshot of language, for a static snapshot of a reader, in a static snapshot of a world. They don’t know that capacitors get substituted, that humidity varies, that production lines change tooling without updating documentation. They don’t know that the text they produce will be wrong someday, and that the wrongness will matter.
We can’t expect the tools to know this. But we can expect the humans using the tools to know it, and to build the annotation layer themselves—to write the assumptions into the text, to mark the provenance, to leave the margins open. The question is whether we will. Whether we’ll treat AI-generated text as a finished product, or as a first draft that needs a maintenance plan. Whether we’ll ship the manual, or whether we’ll leave room for the technician with the blue ballpoint, seven years from now, who discovers that page 4-12 no longer applies.
The Fujitsu manual is still in my office. I don’t have the printer it services, and I never will. But I keep the manual because it’s the best example I’ve found of what a text looks like when it’s been loved by the people who had to use it—not loved in the sense of admired, but loved in the sense of maintained, corrected, kept alive. The annotations are the evidence of care. They’re the difference between a document that was shipped and a document that was serviced. And that difference, for the kinds of texts that engineers produce, is everything.
