I wrote a manual for my own system. Twelve sentences in it were false

On 5 August 2026 I sat down to read my own user manual. Not to polish the style — to check whether it still tells the truth. I went sentence by sentence, looked in the code for the place that was supposed to make that sentence true, and checked whether it was there.

The result: twelve false sentences and nine mechanisms the manual didn't know about at all.

How old is a text nobody marked as old

I started with the cheapest possible check: when did I last change the manual's text file, and how many changes have gone into the system since then. The answer: 51 commits, including five back-end rebuilds and two full-system control passes.

That's a single command, and it gives a number that's enough on its own for a decision. If the counter shows dozens, the manual is already lying — the only question is where.

The most important untruth wasn't a typo

The manual's introduction promised: the panel never contacts anyone on your behalf.

That was false, and in the worst possible place. The collections module was sending emails to clients by itself, from the morning run: a polite reminder after three days, a firm one after ten, and after twenty-one, a formal payment demand with interest. A comment in the code called this, in plain words, the most serious action the system performs without asking. I had written that comment myself, a few weeks earlier, in a different file, and had since managed to forget it.

The sentence in the manual and the comment in the code described two different systems. The real one was the second.

Four untruths from one cause

The chapter on the start screen talked about a "+" button, a "…" menu, and a section whose name doesn't exist in the panel. All three genuinely exist — just in the phone app. I had written that chapter looking at the phone, and it's mostly read on a computer.

Four of the twelve untruths are this single mistake, repeated four times. The other modules I described better: they have a separate sentence, "Phone and iPad: …" This one didn't.

The rest are smaller items from the same family: five ways for a lead to enter instead of six, four kinds of message instead of five, a button called "Create correction" that has long since been renamed "Issue correction," and a menu item pointed one position off. None of them would break anything in the database. Each one teaches that this text isn't worth checking, because it's wrong anyway.

What I did not do

I did not change a single line of the system's behavior. This whole review was about text only. It was tempting in exactly one place: since the sentence "never contacts anyone on your behalf" is false, I could just turn the automation off and make the sentence true. I didn't, because this isn't a bug — it's a business question: do I want a formal payment demand to go out automatically, even to a client I spoke with on the phone yesterday. I wrote down how it actually works, and asked the question separately.

The answer came two days later and was a middle path: the three- and ten-day reminders stay automatic, the formal demand now waits for a click. Had I "fixed" it on the spot that same evening, I would have shipped a variant nobody had chosen.

I did not rewrite the manual from scratch. Rewriting the whole thing would have looked like tidiness, but it would have been the same problem a second time: a text written once, disconnected from the code, just two months fresher.

Three things I take from this

Documentation ages without any symptom. Code that stops working fails a test or a build. A sentence that stops being true does nothing: it compiles, it renders, it looks exactly like it did on the day it was true.

A chapter written from one device lies on another. Not because the author made a mistake — because it describes what was in front of their eyes, and the reader has something else in front of theirs.

An untruth in a manual is sometimes a question for the product, not a typo in the text. The most valuable thing this review gave me wasn't the twelve corrections. It was one question I would never have asked myself if I hadn't tried to describe my own system in a plain sentence.

All numbers — twelve sentences, nine mechanisms, 51 commits — come from a single session on 5 August 2026 and concern a system I built for myself. The commit count comes from the repository's history; the rest I counted by hand, holding each sentence up against the code.