Axiom

Landing Page
Architecture diagram

Inspiration

Software is tested before it ships. School lessons should be too.

We saw this problem firsthand when one of our physics teachers broke down in class because his lesson plans weren't getting through to his students. Teachers often discover unclear explanations, hidden prerequisite gaps, or misleading assessments, only after students struggle - and by then, class time is already gone.

We built Axiom to give every lesson a practice run, using simulated learners to uncover confusion, suggest targeted improvements, and verify those changes before the lesson reaches a real classroom.

What it does

Axiom is a curriculum stress-testing platform that helps teachers find where a lesson could cause confusion, make targeted improvements, and verify them before teaching to students.

Teachers upload lesson(s) and assessment(s) files (preferably with an answer key) along with context on the material's objectives. Axiom parses the files into structured outputs, and assigns stable IDs to each section and question before saving all of it to Supabase.

GPT-5.6's powerful reasoning then analyzes the saved curriculum, before generating five specific learner profiles, ranging from novice to expert in the domain. These include, but are not limited to: missing prerequisites, misconceptions, and confidence behavior. GPT-4o mini then walks each learner profile through lesson ingestion and taking the assessment. This parallels test preparation for real students.

The five learner agents then run concurrently using the OpenAI Responses API. To maximize independence, they're given the lesson plan as their only context with no way of interacting with each other. Every learner answers the uploaded assessment and records its reasoning and confidence per question. A grading engine (typescript rules engine) is then used to measure learners' comfortability with the material, and accuracy on the assessment.

GPT-4o mini then converts these findings into targeted fixes, paired with source evidence, affected content, and expected impact. Teachers can accept or reject each change. Approved patches are then saved.

Finally, Axiom generates fresh learner agents carrying the same initial student profiles, but with no memory of prior attempts. The same pipeline and grading engine used in the initial swarm is ran against the revised lesson and assessment to test the efficacy of revisions.

Afterwards, the educator can see quantifiable metrics that show before/after improvements along with any issues. The final lesson and/or assessment can be exported as a downloadable PDF.

How we built it

OpenAI Integration:
- Codex + GPT-5.6-sol - Code implementation via CLI
- GPT-5.6 medium reasoning - Curriculum analysis
- GPT-4o mini - Simulations + Learner profile generation
Backend (Next.js API Routes):
- profiles.ts - Learner profile generation
- swarm.ts - Concurrent learner simulation orchestration
- calibration.ts - Psychometric outcome calibration
- persistence.ts - Supabase layer
Frontend + Database (Supabase):
- Next.js 15 + React 19 - Full-stack application and interactive screens
- Tailwind CSS + Lucide React - Interface styling and iconography
- PostgreSQL - Persistent curriculum storage
- NDJSON streams - Live simulation updates
Psychometric Simulation:
- calibration.ts - Learner-question probability distributions
- Seeded sampling - Reproducible learner outcomes
- Isolated verification - post-fix agents carry no memory of prior attempts
Testing and Validation:
- Vitest - 46 automated tests
- Zod - Runtime data validation

Codex usage: We were able to implement all of our features using the Codex CLI and GPT-5.6, speeding up our development timeline dramatically. By specifying lint testing in our prompts, Codex accelerated debugging processes, allowing us to add more features than we could in previous hackathons. We also used Codex's non-interactive mode for its parallel task execution. This let us work on multiple features at once with live progress output.

Challenges we ran into

We had some troubles with calibrating the distribution attributes in order to not make results feel scripted. But through trial and error, we settled on a list of core student behavioral traits that yielded realistic and varied outcomes. Additionally, towards the beginning of the project, 2 or 3 tests would already drain compute credit. So, based off of the complexity of tasks, we decided whether to assign low/high-reasoning and GPT-4o/GPT-5.6 (which traditionally uses more credits).

Limitations

Coming up with a way to simulate real students was tough. We initially thought of creating a student-behavior model. But it'd require a large, privacy-sensitive dataset of student responses. We know this option would have likely produced the most authentic results, but real classroom data comes with FERPA and privacy constraints that weren't feasible in the timeframe we had. Instead, we built our behavioral model on Item Response Theory - the same statistical foundation educational organizations like the College Board uses to score the SAT and calibrate scores. Given the constraints mentioned, it was the closest we could get to modeling real student behavior.

Additionally, synthetic learners are not substitutes for real students, and model-based grading can be wrong or reflect shared model biases. Axiom is therefore designed as a preflight diagnostic tool, not proof that a lesson will work in a real classroom. Teachers remain responsible for reviewing every suggested change.

Accomplishments that we're proud of

We're really proud of creating a product that solves an active need for teachers. Creating lesson plans and tests are already demanding tasks for educators, but making sure students engage effectively with them is even harder. We're also proud of completing every feature we spec'd out in our initial PRD (product requirement document). It was also our first time using Codex, and it was one of the most seamless development processes we've had in a hackathon. Because of Codex's elite programming capabilities, we were able to focus more on user-experience and architectural decisions.

What we learned

We learned it's important to push basic versions of features as fast as possible before making tweaks/changes later on. In trying to push perfect features on our first try, we lost some time that could have been used for implementing other ideas.

What's next for Axiom

Noel already talked to 5 of his teachers/professors, and tested lesson plan + assessment pairs on Axiom. After seeing the revised documents, they all told him that Axiom made real improvements to their lessons. We truly believe that our project can massively impact the Ed-Tech industry. Although stress-testing/red-teaming software has made waves in industries like: healthcare, finance, and manufacturing, education has largely been left behind. We plan on:

Creating a custom behavioral model and training it on student essay datasets (alternative for quiz responses due to FERPA/privacy)
Allowing teachers to use a custom amount of learners to reduce standard deviation in samples
Partner with school districts and scale Axiom to a full-on company.