Writing tasks that produce real evidence
The last of three pages on creating quality content for learners. You know what capability you're measuring (Designing competencies and levels) and how a task's fields connect to it (How competencies and evidence connect). This page is about writing the one task in front of you so it actually measures that, for whichever mentor happens to review it.
"I did it" is not evidence
That's the line apprentices see in the app, and it's the standard to author against too. Every evidence expectation you write should describe something a mentor can actually open — a commit, a specific file, a test run, a resolved conflict — never a claim the apprentice makes about their own work. If the only way to check an evidence expectation is to ask the apprentice and take their word for it, rewrite it.
Acceptance criteria should be checkable, not judged
A criterion your mentor has to form an opinion about is a criterion two different mentors will decide differently on:
"acceptanceCriteria": [
"Code is clean and well organized",
"Tests pass"
]versus:
"acceptanceCriteria": [
"No function in the submitted diff exceeds 40 lines",
"'npm test' passes locally with zero failing tests, shown in the evidence note",
"At least one test added in this task fails against the pre-task code"
]Ask, for every criterion you write: could two mentors reading the same submission disagree about whether it's met? If yes, it isn't a criterion yet — it's a reminder to write one. And keep every criterion paired with something in evidence that would actually let a mentor check it; a criterion nothing in the evidence list points at is unverifiable by construction.
Ask for process, not just a final answer
A task whose only evidence is a finished file or a final answer is the easiest kind to satisfy with a single pasted AI response and zero understanding — and the hardest for a mentor to tell apart from genuine work after the fact. Ask for something that only exists if the work actually happened over time: commit history showing incremental progress rather than one commit, a note about a specific decision or conflict encountered partway through, a reflection that answers what was tried and what's still unclear rather than just what the final state is. None of this requires banning AI — pair it with a deliberate choice on the task's AI policy; it just means the evidence you ask for should be hard to fake even when AI assistance was genuinely used and disclosed.
Calibrate difficulty to its place in the path
A term's task order is the academic path an apprentice actually walks — see Curriculum structure basics. Use that order deliberately: each task should ask for a little more independence or ambiguity than the one before it, not repeat the same difficulty under a new name or jump straight from guided to unguided. A term that's flat until one disproportionately hard task at the end teaches an apprentice to dread endings, not to build skill steadily.
The app's minimums are a floor, not a target
Submission is blocked below a 20-character reflection and an 8-character evidence note — see Submitting evidence for review. That floor exists to stop an empty submission, not to define what a good one looks like. Write task instructions that make the bar for a substantive reflection obvious for that specific task — what question you actually want answered — rather than relying on apprentices to infer quality from a character-count minimum that would technically accept "did it, works fine."