Where documentation starts lying after the code ships
Docs do not go wrong all at once. They go wrong at specific, predictable points in a release — and the drift is invisible until someone follows the instructions.
Documentation drift is not a writing problem. It is a timing problem. The code changes on a Tuesday, the docs change whenever someone notices, and in between there is a window where the instructions are wrong and nobody knows it.
The four places it starts
- Renamed flags and options. The most common and the least visible, because the surrounding prose still reads correctly.
- Default values that moved. Copy that says the default is X is still grammatical when the default becomes Y, and still wrong.
- Removed commands that were never removed from the quickstart. The quickstart is the first thing a new user reads and the last thing anyone updates.
- New required steps added to a flow that the docs still describe as three steps.
Why review does not catch it
Code review reads the diff. The docs are not in the diff, so the reviewer has no prompt to check them. Drift that review cannot see has to be detected mechanically, which is what PaperDrift does: it reads the docs against the code and reports the statements that no longer hold.
It reports candidates for review. It does not rewrite your documentation, and a clean run is not proof the docs are correct.