When Autocorrect Never Runs

When autocorrect gets something wrong, the obvious suspect is the model. Perhaps the dictionary is missing a word. Perhaps the candidate score is too low. Perhaps one more adjustment will finally persuade the keyboard that the word I meant is, in fact, the word I meant.

Those are reasonable places to look. They also share an assumption: the correction engine was asked.

Before arguing about the answer

A retrospective report dated September 2026 examined 63 days of typing harvest data. Among 424 instances of the studied surviving common typos, it attributed 346 to input surfaces where candidate evaluation had not run. That is roughly 82 percent of that specific set, not 82 percent of all typing or every error the keyboard could make.

The distinction changes the debugging problem. Improving a candidate's rank cannot help a correction that never entered the competition.

Termux was a substantial part of the report's findings. A terminal is not a conventional prose field. It can expose raw input without the composing-region behaviour a keyboard ordinarily uses to manage suggestions and replacement.

That leaves an awkward gap between two systems doing what their interfaces allow: the application accepts keystrokes, while the keyboard's usual correction path is not being invoked. The word is wrong. The model may have nothing to say about it because nobody asked.

A second path is not a blank cheque

The OmniBoard implementation at commit a47aa0117 adds tracking through internal word and line buffers. It can evaluate corrections outside the usual composing path and attempt a replacement at a word boundary.

Getting as far as a replacement is only half the problem. A terminal contains things that resemble words but should not be treated as prose: command names, flags, paths and fragments of syntax. The implementation uses conservative checks to suppress corrections on those patterns.

That is useful, but it is still a set of heuristics. It does not certify that an arbitrary command is safe to alter. Different terminal applications also handle deletion and cursor state differently. Source code showing the mechanism does not settle the physical-device question.

Put the effort at the right layer

The useful lesson is not that ranking is unimportant. It is that ranking sits downstream of reachability. The system first has to invoke the correction path, then retrieve plausible candidates, then choose among them, then apply the result without breaking the editor state.

A polished improvement to the last stage can leave the first failure entirely untouched.

I want that distinction preserved in the project notes because it makes the work more understandable. A disappointing result does not always demand a more sophisticated model. Sometimes the first useful question is considerably less glamorous: did this part of the system run at all?