The evaluator has a form, not an opinion
They are not deciding whether your submission is good. They are working down a list of required elements and recording, for each one, whether it is present and adequately demonstrated. That is the entire task, repeated across a queue of submissions.
This explains the thing students find hardest to accept, which is that a well-argued document can fail while a plainer one passes. The plainer one made each element easy to locate. Yours may well contain everything required, distributed through prose that reads beautifully and forces somebody to hunt. An element that cannot be found within a few seconds gets recorded as not demonstrated, and no appeal to overall quality changes that.
Structure to the task, literally
The fix is unglamorous and close to universal. Take the task instructions, turn each lettered or numbered requirement into a heading in your document, and answer directly underneath it using the same vocabulary the requirement used.
It produces something that reads more like a form than an essay, which is uncomfortable if you write well. Do it anyway. The document is not being read for pleasure, it is being audited for completeness, and matching your structure to the auditor's list removes the single largest cause of a return. Students who make this one change typically stop bouncing.
- One heading per lettered requirement, in the task's own order
- The requirement's own nouns and verbs repeated in your heading
- A direct answer immediately beneath, before any context or discussion
- Sub-requirements broken out separately rather than folded into a paragraph
- Nothing inferred: if it asks you to justify, the word because should appear
- A final pass reading only the headings, checking every requirement has one
A return is not a judgement on the work
Worth internalising early, because the emotional cost of a bounce is what slows people down rather than the revision itself. Nothing about a returned task is recorded, nobody counts attempts afterwards, and the evaluator holds no opinion about you whatsoever.
What a return costs is days, and in a self-paced program days are the currency. So the correct response is mechanical and fast: read the comment, locate which requirement was recorded as absent, restructure so it cannot be missed, and resubmit inside the week. Students who treat a return as feedback on their ability lose a fortnight to that feeling. Students who treat it as a formatting instruction lose two days.
Two similar requirements are not one requirement
This causes more returns than anything except burying an answer. Tasks frequently include a pair of adjacent requirements that sound nearly identical: describe the approach, and then explain why the approach suits the scenario. Students answer both in one place, considering the second implied by the first.
The evaluator's list has two rows. One gets ticked, the other does not, and the task comes back with a comment that reads as though they missed something obvious. They did not; they were checking separately, as the form told them to. Where two requirements sound similar, treat that similarity as a warning and give each its own heading even where the content feels repetitive.
Technical tasks carry a second, hidden requirement
In IT, cybersecurity and data tracks the deliverable is usually artefact plus explanation, and students concentrate entirely on the artefact. A working configuration, a clean dataset, a functioning script feels like the answer, so the written justification gets produced in the last hour.
But the evaluator can rarely re-run your work, and is often assessing the reasoning rather than the output. Screenshots labelled with what they show, a stated rationale for each significant choice, and an honest note on what you would do differently at scale carry more weight than an extra hour of refinement. Where an evaluator comment has come back and reads like a riddle, translating it is usually a same-day job.
Questions people actually ask.
Why did a strong submission come back?
Almost always because a required element could not be located rather than because the work was weak. Evaluators tick a list, and anything embedded in prose or answered by implication reads as absent. Restructure so each requirement has its own heading in the task's order, and the same content usually passes without a word being added.
Is it acceptable to write in headings and bullet points?
Not just acceptable but advantageous, unless the task specifies a prose format. The document is being audited for completeness rather than read for style, so a structure matching the assessor's checklist is doing them a favour. Students who make this change typically stop having tasks returned.
What if two requirements seem to overlap?
Answer them separately anyway, each under its own heading, even where the content feels repetitive. The evaluator's form has two rows and will tick them independently. Collapsing near-identical requirements into a single answer is one of the commonest causes of a return, and the resulting comment usually reads as though they overlooked something.
How much does the written part matter on a technical task?
More than the artefact, frequently. An evaluator often cannot re-run your configuration or script and is assessing the reasoning instead. Labelled screenshots, a stated justification for each significant decision, and an honest note on limitations tend to earn more than additional polish on the deliverable itself.
Does a returned task go on my record?
No, and nobody tallies attempts once you have passed. Revision is designed into the model. What a return genuinely costs is days, which in a self-paced program is the thing you are actually spending, so the useful response is to treat the comment as a formatting instruction and resubmit quickly rather than as a verdict.
