Organization of knowledge

When knowledge is organized, it is easier to retrieve it from memory.
The better it is organized, the more cues are formed, the easier the retrieval and the faster the retrieval.
Verbalization is one way to organize the knowledge of a chess position. But we already know, that a verbal description is not the most logical way to transfer knowledge from one problem to the next. Besides that, language itself is inherent limited in describing a chess position. It can be used to describe the core ideas, but the details become problematic. That is why I want to use a second method to describe the position: graphical representation. The use of two methods for the organization of chess knowledge has an extra advantage: it provides more cues, hence faster and better retrieval.

When you work out all variations of a given position rated 2000+ the amount of variations usually exceeds hundred moves by far. Of which every move has its own consequences and repercussions on the position. It is possible to compile the essence of the variations in a few chess diagrams with arrows and coloured squares added. In language you would need 100+ little descriptions what the moves are doing. That is not realistic.

I don't know what is the most essential that must be represented, since the possibilities are endless. Probably the mere compilation of the diagrams themselves is the best way to store knowledge to memory, but in the end you will have a file with diagrams which can be used for some repetition if that is needed.

I compiled a few diagrams from different points of view. I haven't decided yet what are the most usefull diagrams. I suspect when working with it you will see a shift overtime. In the beginning you need for instance a way to represent the overworked pieces. But once the recognition of overworked pieces has become automatic, there is no longer the need to document them, since you simply see them. You can find the original problem at CT here.

Diagram 1. The arrows show where the main attackers go

You see that the diagram is some sort of time machine. You see not only how the position is now, but you can see the result of moves too. This provides a glimpse into the future. A representation like this is much less demanding for working memory than the managing of individual moves.

Diagram 2. The coloured squares to show where the main attackers go.

Coloured squares in stead of arrows might give a quieter look. It will become problematic when the attackers converge, though.

Diagram 3. Invasion squares.

Here you can see where two attackers converge on the invasion square c4. The green squares represent the defenders of said square.

Diagram 4. Counter attacks.

In diagram 4 you see the knightfork Ne4 represented in yellow. The arrows show which counterattacks this move would unleash.

Diagram 5. From attacker to target

In diagram 5 you see tactical elements like the two pins and the knightfork in one glance. The blue squares are the focal points of the position.

Diagram 6. Immobilization.

When you think about the combination and the move order, diagram 6 comes in handy. The move Rd4 binds both the knight and the queen to the invasion square c4. It happens to free the black knight from the pin too. The move Qe2 immobilizes the knight even more and binds the white queen to the defence of the knight. After Rd4 and Qe2 the white queen and knight are totally paralyzed and ready for the knightfork Ne4.

Diagram 4, 5 and 6 together seem to represent the core components of the combination pretty well. If we are able to see these invisible structures fast, we would have a whole lot of more time to think about the details, with a working memory that is way less overloaded.