Gap Recovery
“Spot a student's real gaps, then close them as a team.”
openIllustrative team — open seats are real invitations.
- Build mode
- adopt-and-extend
- Built on
- arem (applet-remediation) in apps/k12-learn
- Output
- multi-role web app
The brief
What it is, and why a teacher says yes
The pain point
Remediation is a coordination problem nobody owns. A teacher or tutor knows a student has gaps, but the gaps are tracked nowhere, the materials are scattered across folders and links, and no single person sees the whole picture — least of all the parent. The work of knowing where a student actually stands is paid over and over, by hand.
What it does
A teacher/tutor builds a per-student recovery plan, names the specific gaps (with priority and dependency order), attaches content and practice to each, and assigns it. The student works through it and submits; the teacher grades or requests a redo; the parent watches progress; milestones and notifications keep all three roles in sync. The unit of work is the gap, and the app owns its whole lifecycle.
Why it's adoptable
It removes a real coordination cost teachers and tutors already pay, it's grounded in a real remediation case study, and — crucially — the build already exists (the arem feature ships, with e2e coverage), so a pilot can be prepared without months of construction — though, this being a FERPA/COPPA-scoped app, only after deployment setup and full safeguarding clearance, never “now” in the print-starter sense. And its teacher/tutor “admin” role is the sponsoring teacher: the safeguarding anchor is structural to the app, not bolted on after.
What the teacher receives — a synthetic example
Recovery Plan — Student A (synthetic)
Owner: Tutor (sponsoring adult) · Parent view: linked| Gap | Priority | Depends on | Status |
|---|---|---|---|
| Place value to 1000 (3.NBT) | 1 | — | redo_requested |
| Multi-digit subtraction w/ regrouping | 2 | Place value (gap 1) | not assigned |
Close gap 1 to unblock gap 2
Student + parent on status change
Assignment state machine
redo_requested is terminal — it spawns a new assignment back at assigned, not a loop to in_progress.
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
A teacher or tutor builds a real per-student recovery plan and runs it to completion — assign, submit, grade or redo, close — for a handful of real students (teacher/tutor-side, with genuine student-side use).
- 2
Active use
The same adult reaches for it for the next student and the next cycle, repeated across students and across cycles — not one demo plan but the recurring way they run remediation (teacher/tutor-side).
- 3
Sustained MAU
The app has become how a remediating adult actually runs their caseload — teacher/tutor-side ownership sustained across cycles with genuine student-side use throughout.
Tier 2
Why this is Tier 2
It isn't assembled from blocks, and it costs more to take to a classroom. Naming both burdens honestly.
- It's net-new, not assembled (in build-nature; the builder still adopts-and-extends, because this net-new code already ships). Recovery plans, gaps, gap content, the assignment state machine (assigned → in_progress → submitted → graded, with redo_requested terminal off graded), multi-role auth, notifications, and milestones are all bespoke domain logic. None of it is worksheet-core, marp-slides, or curriculum; the blocks don't ship a recovery workflow.
- It integrates exactly one block, thinly. AI worksheet generation can supply practice for a gap — a useful slice, but a slice. The substance of the app is the workflow around the gap, not the worksheet inside it. A starter is its block; this app merely uses one.
- It logs people in and stores their data. Two role groups — students and parents — authenticate, and the app persists per-student progress, submissions, and plan data. That is a different universe from a printable, and it is the reason the safeguarding load is High.
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
- apps/k12-learn/src/app/arem/ — the app routes, including distinct (student) and (parent) route groups, plus my-gaps and gaps views.
- apps/k12-learn/src/server/arem/ — server logic (the plan/gap/assignment domain and the state machine).
- apps/k12-learn/src/components/arem/, src/hooks/arem/, src/lib/arem/ — UI, hooks, and shared logic.
- apps/k12-learn/e2e/arem/ — end-to-end tests; apps/k12-learn/docs/applet-remediation/ — the feature's own docs.
Rough assembly
- 1Adopt and extend the existing arem (applet-remediation) feature in apps/k12-learn — this is full-stack adoption, not static-page assembly.
- 2Stand up the real backend: two-role authentication (student and parent), a database holding per-student plans/gaps/submissions, and a notification path.
- 3Wire the assignment state machine and verify the (student) and (parent) role boundaries actually enforce access scoping.
- 4Plug in AI worksheet generation thinly to populate practice for a gap, leaving the bespoke recovery-plan/gap/state-machine core as the substance.
The data flow
Caveats — the honest gaps
Scope boundaries
This owns the gap lifecycle for a remediating adult's caseload — it is deliberately not a general LMS, gradebook, or curriculum platform, and the AI block stays a thin practice-populator rather than expanding into content authoring; on the safeguarding side, it persists only the minimum needed to run a plan (no broader student records, analytics telemetry, or data it doesn't already name) — adding any of those is product or safeguarding creep, not this starter.
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
“You already know which kids have gaps — you just have no clean place to track them or the stuff you're using to close them. This sets up a recovery plan per student: you name the gaps in order, attach the practice, assign it. The kid does it and submits; you grade it or send it back for a redo; the parent can see how it's going. Everyone's looking at the same picture instead of you holding it all in your head.”
The pain it lands on
The remediating adult who keeps a mental list of who's behind on what, a folder of scattered worksheets, and no way to show a parent progress without writing it up by hand. The app makes the gap the thing you manage.
Objections → responses
“This looks like a lot to set up versus a printable.”
It is — and that's the trade. It's not a one-off sheet; it's the system you run your remediation in. The build already exists, so the cost is adopting and deploying it (with safeguarding cleared first), not building it from scratch. If you just need a worksheet, use the starter; if you're running recovery for a caseload, this owns that.
“Why do parents need a login at all?”
Progress visibility is the point — parents seeing movement is half of what keeps remediation going. But every login is also data and consent you're responsible for, so we only stand up the parent role where you actually want parents in the loop, and consent is in place first.
“Where does my students' data go?”
This is the honest one: student data is stored — plans, submissions, progress, and for the parent role, a parent account. That puts FERPA/COPPA-type obligations squarely in scope. So before any classroom use, the full safeguarding checklist must be cleared, you (the sponsoring teacher/tutor) own that data, and any real student data is tier-C — external only, never in the repo. We don't pilot this until that's done.
What a pilot looks like
You pick a handful of real students, build a recovery plan for each, and run them to completion — assign, submit, grade or redo, close. Success = you reach for it for the next student and the next cycle, because it's now how you run remediation, not a thing you tried once.
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
- The teacher/tutor “admin” who owns the data — structural here, not a courtesy; there is no informal version of this deployment.
- Minimum version
- The adopted arem app standing up for real — two-role auth (student and parent), a backend persisting plans/gaps/submissions, the assignment state machine, and a notification path — with the role boundaries verified to enforce access scoping. Not a demo.
- Pilot setting
- A real remediation caseload — a classroom, school, after-school program, or community/tutoring setting serving real learners.
- Success evidence
- A teacher/tutor builds a real recovery plan for a handful of students and runs each to completion (assign → submit → grade or redo → close), mirroring the Pilot graduation rung.
- Stop condition
- The safeguarding checklist isn't cleared in full (consent, data-handling review, supervision, escalation), or the (student)/(parent) role boundaries don't actually gate access — either pauses the pilot until resolved.
Safeguarding
High load · FERPA/COPPA in scopeData touched
This app logs in students and parents and persists per-student data: recovery plans, named gaps, attached content, assignment submissions and grades, progress and milestone state, and parent accounts linked to a child. Storing student progress is the product, so it cannot be designed away — that places FERPA/COPPA-type obligations squarely in scope, not optional or avoidable for this solution.
Checklist
- Sponsoring teacher — required program-wide, and here structural: the teacher/tutor “admin” role is the sponsoring adult, and they must genuinely own the student data, not nominally.
- Consent — student/guardian and school consent before any student or parent account is created. Parent logins mean parent consent and a defined purpose, not just student consent.
- Student data / data-handling review — what is stored, where, how access is scoped by role, retention, and deletion. The (student) vs (parent) role boundary must be verified to actually gate access; default to collecting the minimum needed to run a plan.
- Supervision — the sponsoring teacher's role during pilot and sustained use, including who monitors submissions and notifications.
- Communication channels — notifications go over monitored, appropriate channels; no minor (builder or served student) operating over unmonitored personal channels.
- Showcase privacy — any showcase of this app shows impact in aggregate/anonymized form only; no plan, gap, or submission with real student data ever appears publicly.
- Escalation — a defined path for who handles a problem if something goes wrong with stored student data in a school.
One thing to verify
That the (student) and (parent) role boundaries in the adopted arem code actually enforce access scoping — that a parent account can see only its own child's plan and a student sees only their own — before a single real account exists. The safeguarding claim holds only if the role split is enforcement, not labeling.
What would change the load
This one already sits at the high end: logins, persisted per-student plans/submissions, parent accounts, and notifications are intrinsic to the product, which is why the load is High and the full checklist applies. The current profile holds only as long as the footprint stays the minimum needed to run a plan; broadening it — adding telemetry/analytics, free-form student uploads, richer personalized feedback, parent-contact channels beyond the monitored notification path, or retaining data past a cycle's deletion point — extends the footprint and demands the data-handling review be re-cleared before any of it ships.
Want to build Gap Recovery?
Tell us this starter caught your eye — or browse the others first.