SchoolAI
A teacher-in-the-loop platform for reviewing photographed maths homework in Japanese juku, designed around a narrow promise: AI proposes; the teacher remains the final authority.
Role
Independent product engineer — product definition, architecture, backend, frontend and AWS delivery
Open SchoolAIAsync
AI processing pipeline
Human
Final review authority
Multi-tenant
Role and school boundaries
The problem
Paper homework still carries valuable evidence: not only the final answer, but the first wrong step. Reviewing it consistently is slow, and a generic chatbot does not fit a school workflow.
The product hypothesis is deliberately narrower than “an AI school”: capture a real solution, identify the likely mistake, route the suggestion to a teacher, and turn the approved result into the next learning action.
Architecture shaped by trust
The AI path is asynchronous so a slow or failed model call cannot block the rest of the school workflow.
- Cognito and tenant-aware authorization separate school, staff and student contexts.
- FIFO jobs, persisted state and WebSocket updates turn inference into an observable workflow instead of one fragile request.
- AI output is a suggestion. Approval, correction and rejection are explicit product states.
Key product and engineering decisions
Protect the existing workflow
The first use case sits on top of paper homework instead of requiring a school to replace its curriculum or operating system.
Separate inference from authority
Model confidence is not treated as a teacher decision. Human review is part of the architecture, not a disclaimer added to the UI.
Design for failure and cost
Queueing, retries, persisted job status and provider boundaries make latency, failure and inference cost visible product concerns.
Stop adding surface area
The codebase proves broad product execution; the next milestone is customer and quality evidence, not another module.
What exists today
The implemented product covers multi-tenant roles, assignments, photographed submissions, asynchronous AI analysis, teacher review, feedback delivery, skill evidence and operational views.
That is engineering evidence, not product-market proof. The current decision is a bounded validation run: narrow the supported maths scope, measure review quality and time saved, and secure a real pilot before expanding the roadmap.
Public case study, private source
Private sourceThe source repositories remain private. This case study intentionally describes the problem, system boundaries and decisions without publishing credentials, endpoints, child data, private screenshots or implementation details that would weaken security.
Next validation
- →Build a consented evaluation set for the supported maths scope
- →Measure teacher acceptance, unsafe misses and time saved
- →Run one small juku pilot before committing to further product expansion
Technology