The problem with the question is the false assumption that steps 2. and 3. need to be completely separate processes.
By making them separate, it leads to some confusion and redundancy.
I suggest the following:
2 a) Needs Improvement, I use this status to tell the user that his submission needs a correction/revision before it can be approved. Action:
improve() triggered by Me, event fired:
2 b) Improved, the user has submitted a correction/revision as requested. Action:
improve() triggered by the User, event fired:
Both you and the user trigger the same action
improve(). If you trigger the action, then the
improving event is fired and the status is set to Needs Improvement. If the user triggers the action, then the
improved event is fired and the status is set to Improved.
Depending on who triggers the action
improve(), the system fires the appropriate event.
This also allows for you to look at an improvement and determine if it needs further improvement, thereby allowing multiple iterations until something is finally approved (or possibly rejected).
Note: If changing the code to accommodate this simpler status-based flow isn't an option, I still recommend only presenting two status messages to the user: Needs Improvement and Improved. (With a possible interim Improving.) One represents that they need to work on something, the other that they've already worked on it and returned it for further review.
Regardless of what you name the functions and events in the code—or what you see when looking at the interface—having synonyms for needs improvement, improved, or even rejected (as with the soft-rejected idea from a comment) at the same time as the original will result in users become puzzled and perhaps complaining about the extra words and status messages.
If there must be an extra status message shown to the user, I suggest Under Review (
reviewed). It's neutral, without the somewhat negative connotation of Soft-Rejection that's been mentioned in comments.