Technical build brief · MVP core
Academy OS — MVP Build Spec
A developer-ready definition of the first build of Academy OS: grades 3–5 pilot environment, core services, student-state model, routing rules, APIs, and build phases aligned to proving that a personalized orchestration system can run a real academic block.
Build target
Build one production-feasible operating loop for one small pilot environment.
The system must support:
- one student hub for daily lesson flow
- one teacher classroom dashboard for monitoring and intervention
- subject coverage across math, reading, and grammar
- routing across a small connector set
- progress interpretation from connected tools
- deterministic next-step decisions with teacher override capability
Pilot environment
Exact first deployment shape
- roughly 10 students
- grades 3–5
- one core academic block
- one adult responsible for observing pace, intervening when needed, and keeping the learning block coherent
- one primary tool per subject area where possible
- a small connector set only
Non-goals
- no full SIS replacement
- no district analytics layer in V1
- no attempt to support every subject or grade band at launch
- no full autonomous school model
- no AI-generated curriculum as the primary engine
Primary success test
The pilot should show that students can move through a personalized academic block from one hub, while the teacher can monitor, intervene, and adjust from one dashboard without manually stitching together multiple separate systems.
Core services
Required backend components
- integration adapters
- identity / roster mapping
- event normalization service
- student-state engine
- routing engine V1
- alert engine
- teacher dashboard API
- learner API
- student profile API
- teacher override / intervention log service
MVP-core frontends
Required first-build surfaces
- Learner Home
- Teacher Monitor
- Student Profile
School dashboard, parent communication, and broader reporting can come later.
Student-state model
Core domain entities
- Student
- PlatformAccount
- NormalizedEvent
- StudentState
- Alert
- RouteStep
- InterventionNote
- TeacherOverride
State definitions
Academic state
- On track
- Minor friction
- Stalled
- Needs support
- Ready to advance
Attention / engagement state
- Engaged
- Slowing
- Idle risk
- Off task
- Recovered
- Completed block
Alert logic V1
Deterministic alert rules
The first alert system should remain explainable.
Examples:
- repeated misses on the same skill
- extended dwell time without progress
- stalled lesson completion
- unusual pace drop
- repeated redirection need
- ahead-of-pace opportunity
Routing rules V1
Deterministic routing rules
Version one should support:
- continue sequence
- repeat or retry
- move to support item
- pause and wait for teacher action
- advance to next lesson
- unlock extension work
Build principle
What must remain explainable
- why a student is flagged
- why a route changed
- what signals contributed to that decision
- what teacher action is recommended next
- what the teacher can override
If the system cannot explain itself plainly, it is not ready for a real classroom.
Build phases
Implementation sequence
- Lock pilot assumptions, connector set, and daily flow.
- Define schemas, student-state model, and event contracts.
- Ship the first connector end-to-end.
- Build learner flow and teacher monitor on live or sample data.
- Implement state interpretation, alerts, and teacher override loop.
- Add secondary and tertiary connectors only after the first loop is stable.