diff --git a/Submission-flow.md b/Submission-flow.md
index c48e45f..ca16da8 100644
--- a/Submission-flow.md
+++ b/Submission-flow.md
@@ -1,39 +1,35 @@
 # Submission flow
 
-This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution. Only hot path is considered in following description.
+This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution.
 
 ## Web Application
 
 First thing user has to submit his/hers solution to web application which provides interface to upload multiple files and then submit them. More detailed description follows:
 
-- user upload file by file into prepared submit form
-- after uploading all files connected to assignment user click on submit button
-- Web Application send request to Web API that user wants to evaluated assignment with provided files
+1. user upload file by file into prepared submit form
+2. after uploading all files connected to assignment submits solution
+3. Web Application send request to Web API that user wants to evaluate assignment with provided files
 
 ## Web API
 
-After user submit solution then web application has to hand over all needed information about submission to broker. Submit endpoint is extended with support of "cross-submitting" which means that user with high privileges (supervisor, administrator) can submit solution for user with lower privileges (student). More detailed description follows:
+After user submits solution then web application has to hand over all needed information about submission to broker. Submit endpoint is extended with support of "cross-submitting" which means that user with high privileges (supervisor, administrator) can submit solution for user with lower privileges (student). More detailed description follows:
 
-- suitable assignment and user are obtained from database
-- instance license, deadlines and limit of numbers of submissions are checked
-- runtime configuration is automatically detected if not provided as post parameter
-- submission as database entity is created and persisted
-- job configuration is obtained and loaded from selected runtime configuration
-- configuration is extended of proper fileserver address and identification
-- submitted files from user and job configuration are uploaded to fileserver using http post request
-- several information about submission are sent back to user
-    - alongside other information address of websocket which can be used for watching evaluation progress is sent
+1. deadlines and count of submissions are checked
+2. programming language of uploaded files is automatically detected
+3. based on programming language proper job configuration file is obtained
+4. submitted files from user and job configuration are uploaded to fileserver as archive
+5. send message to broker that there is new submission
+6. several information about new submission including websocket channel are sent back to user
 
 ## Broker
 
-Broker gets information about new submission from web application. At this point broker has to find suitable worker for execution of this particular submission. When worker is found and is jobless, then broker send detailed submission to worker to evaluation. More detailed description follows:
+Broker gets information about new submission from Web API. At this point broker has to find suitable worker for execution of this particular submission. When worker is found and is jobless, then broker send detailed submission to worker to evaluation. More detailed description follows:
 
-- broker gets multipart "eval" message from web application with job identification, source archive URL, result URL and appropriate worker headers
-- headers are parsed and worker which matches all of them is chosen as the one which will execute incoming submission
-- whole execution request is saved into `worker` structure to waiting queue
-- if chosen worker is not working right now then incoming request is forwarded directly from waiting queue to worker through multipart message
-- if worker queue is not empty then nothing is done right now
-    - execution of this particular request is suspended until worker complete all previous requests
+1. broker gets message from Web API about new submission
+2. based on information from Web API, broker has to choose suitable worker which matches all submission criteria
+    1. if worker is not working at the moment, broker immediatelly sends job evaluation request to it
+    2. otherwise evaluation request is queued to this particular worker
+3. broker sends evaluation request to worker with all information which was obtained from Web API
 
 ## Worker