diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 44c347f..28ed9bd 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -1485,18 +1485,40 @@ thanks to the simple authentication flow. Replacing these services in a Nette
 application is also straightforward, thanks to its dependency injection
 container implementation.
 
-@todo: mail reports - to users, admins
+#### Solution loading
+
+When a solution evaluation on backend is finished, results are saved to
+fileserver and API is notified by broker about this state. Then some further
+steps needs to be done before the results can be presented to users. For
+example, these steps are parsing of the results, computating score or saving
+structured data into database. There are two main possibilities of loading:
+
+- immediately
+- on demand
+
+They are almost equal, none of them provides any kind of big advantage. Loading
+solutions immediately is better, because fetching results from client for the
+first time can be a bit faster. On the other hand, loading them on demand when
+they are requested for the first time can save some resources when the solution
+results are not important and no one is interested in them.
+
+From this choice, we picked up lazy loading when the results are requested.
+However, concept of asynchronous jobs is then introduced. This type of job is
+useful for batch submitting of jobs, for example rerunning jobs which failed on
+worker hardware issue. These jobs are typically submitted by different user than
+author (administator for example), so original authors should be notified. In
+this case it is more reasonable to load the results immediately and optionally
+send them with the notification. Exactly this is also done, special asynchronous
+jobs are loaded immediately with email notification to the original job author.
+
+From a short time distance it seems that immediate loading of all jobs could
+simplify loading code and has no major drawbacks. In the next version of ReCodEx
+we will rethink this decission.
 
 @todo: what files are stored in api, why there are duplicates among api and fileserver
 
-@todo: groups and hierarchy, describe arbitrary nesting which should be possible
-within instance and how it is implemented and how it could be implemented
-(describe only implementation if it is something what to say)
-
 @todo permission handling, roles, etc.
 
-@todo: on demand loading of students submission, in-time loading of every other submission, why
-
 #### Backend management
 
 Considering the fact that we have backend as a separate component which has no