diff --git a/Rewritten-docs.md b/Rewritten-docs.md
index 2ba6049..99d5ab3 100644
--- a/Rewritten-docs.md
+++ b/Rewritten-docs.md
@@ -1603,37 +1603,39 @@ permission checking with quite a small amount of code.
 
 #### 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, computation of 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 (administrator 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 decision.
+When a solution evaluation on the backend is finished, the results are saved to
+the fileserver and the API is notified by the broker. Some further steps needs
+to be done at that moment before the results can be presented to the users.
+Some of these steps are parsing of the results, calculation of the final score,
+or saving the structured data into the database. There are two main
+possibilities when to process the results:
+
+- immediately after the API server is notified by the backend
+- when a user requests the results for the first time
+
+These options are almost equal, none of them provides any kind of a big
+advantage. Loading solutions immediately is better, because fetching results
+by the client for the first time can be a bit faster as the results are already
+processed. On the other hand, processing the results on demand can save some of
+the resources when the solution results are not important (e.g., the student
+finds a bug in his solution before the submission has been evaluated).
+
+We decided for the lazy loading at the time when the results are requested for
+the first time. However, the concept of asynchronous jobs is then introduced.
+This type of job is useful for batch submitting of jobs, for example re-running
+jobs which failed on a worker hardware issue. These jobs are typically submitted
+by different user than the author (an administrator for example), so the original
+authors should be notified. In this case it is more reasonable to load the results
+immediately and optionally send them a notification via an email. This is exactely
+what we do.
+
+It seems with the benefit of hindsight that immediate loading of all jobs could
+simplify the code and it has no major drawbacks. In the next version of ReCodEx
+we will re-evaluate this decision.
 
 #### Backend management
 
-Considering the fact that we have backend as a separate component which has no
+Considering the fact that we have the backend as a separate component which has no
 clue about administrators and uses only logging as some kind of failure
 reporting. It can be handy to provide this functionality to backend from
 frontend which manages users. The simplest solution would be again to have