Again, it depends very much on how you define 'documenting'.

Here, the most important life-cycle comments in the source code are not what it was meant to do (that can be rather self=-evident), but details like WHY a change was made, and what was tried that did NOT work.

The devil is in the details, and 'what you have to do' is much easier to state, than the details of getting there, using what you can get.

Some companies fail to grasp that 'collective wisdom' matters, and those are usually the ones who go down in a screaming heap when a bean-counter imagines they can 'just outsource R&D'.