Quiz + Key, Done
“A fair quiz on exactly what you taught — with the key.”
Illustrative team — open seats are real invitations.
- Build mode
- assemble on blocks
- Built on
- @k12vls/worksheet-core + @k12vls/curriculum
- Output
- printable PDF
The brief
What it is, and why a teacher says yes
The pain point
Writing an aligned quiz and its answer key is a perennial time sink — and it recurs every unit, for every section. The work is doubled (quiz + key) and the alignment has to be defensible if a grade is challenged.
What it does
Teacher picks the standards covered this week → generates a quiz aligned to that set of standards plus the matching answer key, as a printable PDF. One pass produces both the student copy and the grading copy.
Why it's adoptable
Assessment is universal — every teacher writes quizzes — and the alignment-to-what-was-taught promise is the hook: a quiz built from the standards you actually covered, not a generic bank item that drifts off-topic.
What the teacher receives — a synthetic example
Unit Quiz — Expressions & Equations
- Solve: 3(x + 4) = 27. 7.EE.B.4
- A shirt is $24 after a 20% discount. Original price? 7.EE.B.3
- Write an expression for “5 less than twice n.” 7.EE.B.4
… 7 more, sampled across the unit …
Answer Key — Grade 7 · 7.EE
- x = 5 (3x + 12 = 27 → 3x = 15)
- $30 (24 ÷ 0.80)
- 2n − 5
Illustrative mockup. All example data is synthetic — no real student data.
The graduation signal
“Built” doesn't count — real, repeated use does. Here's the ladder.
- 1
Pilot
One generated quiz used in a real grading cycle, not a demo print (teacher-side; students never log in).
- 2
Active use
The teacher reaches for it each time a unit closes, replacing the by-hand quiz-and-key habit (teacher-side).
- 3
Sustained MAU
A teacher returning unit after unit, across multiple sections — repeat use that means it stuck. Since students never log in, this is teacher-side MAU; the student participants are estimated from classes served, not counted as logins (teacher-side MAU).
For the AI Builder
How you build it
The honest build path — what it builds on, the rough assembly, the data flow, and the gaps the blocks don't give you for free.
Blocks it builds on
- @k12vls/worksheet-core — provides the CCSS standards model (GradeID, CCSSStandard, the standards tree), the problem-generation config + record types (CcssProblemGenerationConfig, CcssProblemRecord), the problem-generation prompt constants (getProblemGenSystemPrompt), rendering UI (@k12vls/worksheet-core/ui), and a PrintOptions type + print styles. It also ships a submission/grading model (SubmissionStatus, GradingStatus, grading utilities like calculatePercentage, getTotalScores) — but for a print quiz you don't need the grading runtime; the “key” is just the generated answers rendered alongside the questions.
- @k12vls/curriculum — the curriculum data/utilities the standards selection draws on.
- The distinctive element — multi-standard selection. Unlike a single-standard worksheet, a quiz spans several standards covered in a week. The selector lets the teacher tick the standards the unit touched, and a CcssProblemGenerationConfig per standard (each with its own numProblems) drives generation across all of them — so the quiz samples across the selected standards, not just one. The tool only knows which standards were selected, not how much class time each got, so it can't infer instructional emphasis on its own; if the teacher wants to weight a heavily-taught standard, they set a higher per-standard item count (the items-per-standard control). Don't claim the quiz proportionally mirrors what was taught unless the teacher supplies those weights.
Rough assembly
- 1Pick — a grade + multi-select standards picker, populated from the worksheet-core CCSS standards tree; the teacher checks the standards covered this week, sets the total quiz length (numProblems), and optionally adjusts items per standard to weight emphasis (default: spread evenly across the selected set).
- 2Generate — for each selected standard, call the LLM with getProblemGenSystemPrompt(...) + a CcssProblemGenerationConfig carrying that standard's numProblems, producing problems and their answers (CcssProblemRecord); merge into one quiz. The per-standard counts are what make the sampling even-by-default or teacher-weighted.
- 3Render — display the quiz (questions only) and the answer key (same items with answers) using the worksheet-core ui components.
- 4Print — apply PrintOptions / print styles; the teacher prints the quiz and key, or “Print → Save as PDF.” (See caveat.)
The data flow
CcssProblemGenerationConfig across the set.getProblemGenSystemPrompt.CcssProblemRecord).worksheet-core/ui).PrintOptions.Caveats — the honest gaps
Scope boundaries
This is a print-only quiz-and-key generator, not an assessment platform: it does not capture submissions, grade student work, store scores, or track who took what — wiring in the available SubmissionStatus / grading runtime would turn it into a bigger thing and make it start touching student data, which is exactly the line this starter holds.
For the AI Champion
Taking it to a teacher
The adoption kit — the pitch, the pain it lands on, the objections you'll hear, and what a real pilot looks like.
The 30-second pitch
“Tell it which standards you covered this week, and it prints a quiz on exactly those — plus the answer key. You stop writing both the quiz and the key by hand. No logins, nothing for students to set up.”
The pain it lands on
The end-of-unit grind: building a fair quiz that matches what you taught, then writing the key to grade it — every unit, every section.
Objections → responses
“Is it really aligned to what I taught, not some generic bank?”
You tick the exact standards you covered; the quiz samples across that set and nothing off-topic — and if you taught one standard harder than another, you set how many items each gets.
“Writing the key is half the work — does it do that too?”
Yes. The same pass produces the answer key alongside the quiz; you print both.
“Where does my students' data go?”
Nowhere. It generates a printable quiz and key; no student logs in, no submissions are captured, and no student data is stored (the quiz and key are yours to keep, like any lesson material).
What a pilot looks like
The teacher uses one generated quiz in a real grading cycle. The real test is the next unit — success = they reach for it again instead of writing the quiz and key by hand, unit after unit.
The bar
Safeguarding & the pilot gate
The minimum conditions before any classroom use, and the data posture that keeps the solution honest.
Pilot gate
- Sponsoring adult
- A classroom teacher (or the sponsoring adult at a school, after-school program, or community setting where real learners are served).
- Minimum version
- Multi-standard pick → generate quiz + matching answer key → print/save-as-PDF, with the alignment-to-selected-standards promise actually holding — not a single hard-coded sample.
- Pilot setting
- A real end-of-unit grading cycle in a class period (not a demo print).
- Success evidence
- The teacher reviews the generated quiz and key first — checking correctness, fairness, and alignment — and then uses them in a real grading cycle, judging them fair and aligned to what they taught. Because this feeds a grading cycle, a generated quiz never goes to students unreviewed; the sponsoring teacher's check is a required step, not optional polish.
- Stop condition
- Immediate — at review the teacher finds the quiz off the standards selected (off-topic or misaligned items), the answer key wrong, or items unfair, and won't give it to students. Over the pilot — the build can't avoid the submission/grading path or a login requirement — anything that breaks the “aligned, no student data” promise.
Safeguarding
Lowest loadData touched
No student data — the teacher-selected grade + multi-standard set generate the quiz and key (and pass through the LLM problem-generation call); no student login, no submissions, no PII, no uploads, no completed student work. No student data is persisted. The generated quiz/key itself is an artifact — the teacher may print, download, or save it as ordinary lesson material — but it contains no student data, so saving it carries no data risk. (The grading runtime that would touch student data is deliberately left out — see the build caveat.)
Checklist
- Sponsoring teacher ✓ (required program-wide).
- Data-handling review n/a (no student data captured).
- Consent n/a.
- Content review applicable — the quiz and key are LLM-generated and feed a grading cycle, so the sponsoring teacher must verify correctness, fairness, and alignment before students sit it. (Not a data-handling item — the tool touches no student data either way — but a required classroom/assessment quality gate.)
- Supervision = ordinary classroom assessment use.
One thing to verify
That the build genuinely avoids the submission/grading path (SubmissionStatus, getTotalScores, etc.) and any login requirement (see the firebase-auth caveat), so the “no student data” claim holds in practice, not just in intent.
What would change the load
The Lowest profile holds only while the artifact stays a printed quiz + key. The clear triggers — a student login, capturing submissions or scores (the available grading runtime), saving student work, or personalized per-student feedback — each make it touch student data, at which point consent / data-handling review stop being n/a. Telemetry splits by what it's tied to: product telemetry on generation events (a count of “a quiz was generated for these standards,” no student or class identity) is not a student-data trigger; but telemetry tied to teacher/class/assessment history — which class sat which quiz, a per-class assessment record — links to student/class identity and does move the load up. Log the former freely; treat the latter as crossing into student data.
Want to build Quiz + Key, Done?
Tell us this starter caught your eye — or browse the others first.