How BTEC IT assessment works — and where it bites
BTEC IT shares the assessment machinery with every other BTEC — grids, bands, verbs, IV — but its evidence is artefacts: the system you built, the database you configured, the code you wrote. That changes the traps. Here's the guide.
What's identical (by design)
- Criteria grids per learning aim; codes and anatomy the same.
- Band rules: all Pass criteria or the unit caps; Merit/D stack on top.
- Command verbs govern depth — "implement" has a different standard than "implement and test", and "justify your design decisions" is a Distinction-shape criterion.
- Same resubmission rules — one per assignment, Lead IV authorised (guide).
What's different: the evidence is a thing
IT criteria ask for working artefacts — a configured system, a tested program, a maintained dataset. Evidence patterns that work:
| Evidence type | Works for | Failure mode |
|---|---|---|
| Screenshots with captions | Configuration/implementation criteria | Uncaptioned screenshots that show nothing criterion-specific |
| Artefact + written walkthrough | Implementation criteria with review/justification | The artefact alone — most criteria want the decisions explained, not just the result |
| Test plans & results tables | Testing criteria | "All tests passed" with no documented test design |
| Version history / commit logs | Authentication of development work | A finished artefact with no process trail (see below) |
The three IT-specific traps
- The artefact without the reasoning. A working database earns implementation Passes; the Merit/Distinction criteria usually ask why those choices, what alternatives, what the testing showed. Learners ship the thing and skip the justification — the classic band cap.
- Copy-paste configurations. A tutorial walked through verbatim produces artefacts indistinguishable from understanding, until the criterion asks the learner to justify or adapt. Same authentication logic as AI-written prose: the viva question ("why is this field indexed?") settles it.
- Group projects, individual criteria. The system was built by three people; the criteria are per learner. Apply the group-work separations ruthlessly in IT — individual components assessed separately, process evidence per learner.
Verification of IT units
IVs follow the same criterion trail; "evidence location" in IT means the screenshot set, the appendix section, the commit range. The written components — justifications, reviews, documentation — are where most criterion verdicts actually live, and they're exactly what criterion-level checking handles: checkb.tech reads IT units' written evidence against the official grids (see the criteria library) with per-criterion verdicts and cited evidence, leaving the IV's eyes for the artefacts.
FAQ
Do screenshots count as evidence?
Yes — captioned and criterion-relevant. The caption is what turns a picture into assessment evidence: what it shows, which criterion it serves.
How is code assessed fairly?
Against the criteria: does it implement what the criterion asks, is it tested as asked, is it justified as asked. "Elegant" isn't a criterion; "working, tested and justified" usually is.