Blame

07dce2 jeremy 2026-04-12 19:41:51
Add C01-1 checkpoint proposal for design brief readiness Proposes student self-check criteria, teacher quick-check, and feedback prompts for Checkpoint A (Design Brief Ready). For Jeremy's review. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1
# C01-1 Checkpoint Proposal: Design Brief Ready
2
3
**Status:** Proposal (pending Jeremy's approval)
4
**Created:** 2026-04-12
5
**Source:** TKT-004 — C1-1 Assessment Package
6
7
---
8
9
## Checkpoint A: Design Brief Ready
10
11
This checkpoint gates C1-1 (Design Brief Presentation). A student who completes all items is ready to join the presentation queue. A student who hasn't completed the checkpoint uses class time to finish --- naturally reducing their validation time and depth.
12
13
### Student Self-Check Criteria
14
15
Students can check each item themselves before the lesson:
16
17
1. **Problem/need/opportunity stated** --- Brief has a clear section naming a specific, concrete problem, need, or opportunity.
18
2. **Solution described** --- Brief explains what the software does and how it addresses the problem. A reader unfamiliar with the project could understand the idea.
19
3. **Users identified and described** --- Primary and secondary users are named with enough detail to picture them (not just "students" but specific types of users with context).
20
4. **Programming language stated with reasons** --- Language or framework is named with an explanation of why it suits the project.
21
5. **Feasibility and originality addressed** --- Brief includes a section on whether the project is achievable and what makes it different.
22
6. **Artefact ready** --- Brief committed to GitHub, printed copy in hand, cue card prepared (quarter A4, key talking points only), practiced presenting at least once timed at ~5 minutes.
23
24
### Teacher Quick Check (circulating, <60 seconds per student)
25
26
| Check | What to look for |
27
|-------|-----------------|
28
| Printed brief | Physical copy on desk, covers all 5 content sections. They exist and say something specific. |
29
| Cue card | Quarter A4 or smaller. Key words, not a script. |
30
| Quick verbal | "In one sentence, what problem does your project solve?" Clear + specific = ready. |
31
32
### Feedback Prompts (done to strong)
33
34
| Area | Prompt |
35
|------|--------|
36
| Problem too vague | "Your problem is generic. Which specific people have this problem and when?" |
37
| Users generic | "You say 'teachers and students.' What does a teacher actually do with your app first?" |
38
| Language thin | "You chose Python. Why Python and not something else? What does it give you?" |
39
| Feasibility missing | "I see what you're building but not why you can build it. What's your argument?" |
40
| Originality unclear | "If I Googled this, what would I find? What's your twist?" |
41
| Ready for depth | "Now think about weaknesses. What could go wrong, and what would you do?" |
42
43
---
44
45
## Proposed Checklist Integration
46
47
**Where:** C01-2026 checklist, before the C1-1 assessment tasks.
48
49
**Suggestion:** Group learning tasks under "Checkpoint A tasks" heading so students can track their readiness. The checkpoint items above become the self-assessment criteria at the end of the learning sequence, before the presentation.
50
51
**Note:** The full assessment package (teacher protocol, question bank, scoring guide) is in `SD26-Teachers/sat/C01-2026/C01-1-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist.