I had a look at [1]. I believe it is interesting but for me, this document is hard to understand.
The thing is imo, you have a theory of mind on which you build. This building is done in a very structured way and works well for you. I believe the gist is, you have premises, eg. values of a code base, and build further on that, layer by layer.
The OP explains a pain point with sofware engineering, which also applies here: a theory cannot be fully expressed. The code and documentation flows out of the theory, they are artefacts, products of it. Still those are not encompassing the theory in itself, which in fact only exists in the originator's mind.
The job of many sw engineers is to get insights into such theories by inspecting the code and documentation, using it and approaching these from different angles. A bit like archeology.
The thing is imo, you have a theory of mind on which you build. This building is done in a very structured way and works well for you. I believe the gist is, you have premises, eg. values of a code base, and build further on that, layer by layer.
The OP explains a pain point with sofware engineering, which also applies here: a theory cannot be fully expressed. The code and documentation flows out of the theory, they are artefacts, products of it. Still those are not encompassing the theory in itself, which in fact only exists in the originator's mind.
The job of many sw engineers is to get insights into such theories by inspecting the code and documentation, using it and approaching these from different angles. A bit like archeology.