Academy OS — Founder Pilot Plan

Pilot goal

Build the smallest real version of Academy OS that can test whether a personalized orchestration model improves the coherence and effectiveness of a core academic block before broader school deployment.

Locked pilot assumptions

What the first pilot is

• roughly 10 students
• grades 3–5
• one core academic block
• math, reading, and grammar as the first subjects
• one teacher or guide monitoring and intervening as needed
• one student hub organizing the block
• one teacher dashboard managing visibility and support

What is being proven first

The first question is whether Academy OS can run a more individualized and coherent academic block through one system, not whether it can transform an entire school immediately.

What is being proven later

Once the learning model works in the pilot, broader validation can test teacher acceptance, school implementation fit, connector expansion, and larger-scale deployment.

Block model

How the academic block should run

Block start
Student check-in + path assignment
Students open Academy OS and receive the day’s sequence across math, reading, and grammar.

Core work
Platform-led + system-organized learning
Students move through individualized work while the teacher monitors pace, progress, and struggle.

Intervention
Teacher support when needed
If students stall, disengage, or hit repeated difficulty, the teacher uses the dashboard to intervene.

Completion
Core target closes
Once the core path is complete, the system marks completion and teacher attention can shift toward broader work.

Extension
Broader learning opens
The regained time can be used for richer instruction, discussion, projects, or other broader learning.

What to build first

• Learner Home
• Teacher Monitor
• Student Profile
• Basic routing rules
• Progress logging
• Teacher override loop

What should stay manual at first

• some route changes
• some lesson assignment adjustments
• intervention note detail
• broader-learning recommendations
• some import or sync processes if needed

Pilot metrics

What success should be measured by

• student ability to move through the core block from one central system
• teacher ability to understand who needs help and why
• reduced fragmentation in the classroom workflow
• meaningful progression through individualized pathways
• teacher-reported usefulness and coherence
• evidence that the orchestration model supports real learning rather than just cleaner monitoring

Failure conditions

How to know the pilot is not working

• students remain confused by the system
• routes feel arbitrary or unhelpful
• the teacher monitor does not improve intervention
• the teacher feels more burden, not less
• the system does not reduce fragmentation
• the block does not become more coherent in practice

Immediate execution

What to do next

• choose the first subject tools
• confirm pilot location, schedule, and teacher
• define the exact student daily flow
• lock what remains manual in V1
• finalize pilot metrics
• scope the first working prototype
• run fake-student simulations before real use

Practical principle

The first version should not try to automate everything. It should make the academic block run better, make student pathways more visible and more individualized, and create enough proof to justify broader deployment later.