Give your AI tutor a memory of what each student actually knows
LearnState turns raw practice history into calibrated mastery estimates and next-item predictions, so your tutoring app adapts on evidence.
In development. Two endpoints, one job.
// Send what just happened
POST /v1/update
{
"learner_id": "lrn_8f3ka92j",
"events": [{
"item_id": "itm_alg2_0417",
"skill_ids": ["linear-equations"],
"correct": true,
"response_ms": 14200,
"ts": "2026-07-20T14:02:11Z"
}]
}// Ask what they know now
POST /v1/predict → 200 OK
{
"mastery": {
"linear-equations": {
"p": 0.83, "ci": [0.74, 0.90]
},
"factoring": {
"p": 0.41, "ci": [0.29, 0.54]
}
},
"next_item": {
"itm_alg2_0521": { "p_correct": 0.66 }
}
}LLM tutors are fluent. Their model of the learner is a guess.
Language models explain beautifully, but they hold no grounded estimate of what a specific student has mastered. Research on LLM mastery judgments shows they can fall below random chance. So "adaptive" tutoring today mostly means vibes.
No learner state
Each session starts from scratch. The tutor cannot tell a struggling student from a bored one, because nothing tracks what the practice history implies.
Overconfident judgments
Ask an LLM "has this student mastered fractions?" and you get a confident answer with no calibration behind it. Confidence without calibration is noise.
The science is stuck in papers
Transformer knowledge tracing over item embeddings is the published state of the art. Almost no tutoring team can afford the learning-science staff to productionize it.
Practice events in. Calibrated probabilities out.
LearnState is the measurement layer between your app and your adaptivity logic. You keep the pedagogy; we keep the state.
Stream practice events
Every attempt your learners make goes to POST /update: item, skills touched, correctness, response time. That trace is the evidence base.
Transformer knowledge tracing
A compact transformer reads the trace over LLM embeddings of item content, then a calibration layer maps raw scores to probabilities you can trust.
Query learner state
POST /predict returns per-skill mastery with confidence intervals, plus predicted correctness on candidate next items. Route the next question on numbers.
Two calls. That is the whole surface.
Designed so a single developer can integrate in an afternoon, without schema migrations, model hosting, or a learning-science hire.
// Request
{
"learner_id": "lrn_8f3ka92j",
"events": [
{
"item_id": "itm_alg2_0417",
"skill_ids": ["linear-equations"],
"correct": true,
"response_ms": 14200,
"ts": "2026-07-20T14:02:11Z"
},
{
"item_id": "itm_alg2_0418",
"skill_ids": ["factoring"],
"correct": false,
"response_ms": 31400,
"ts": "2026-07-20T14:03:05Z"
}
]
}
// Response 202
{ "accepted": 2 }// Request
{
"learner_id": "lrn_8f3ka92j",
"skill_ids": ["linear-equations", "factoring"],
"candidate_items": ["itm_alg2_0521", "itm_alg2_0533"]
}
// Response 200
{
"mastery": {
"linear-equations": { "p": 0.83, "ci": [0.74, 0.90] },
"factoring": { "p": 0.41, "ci": [0.29, 0.54] }
},
"next_item": {
"itm_alg2_0521": { "p_correct": 0.66 },
"itm_alg2_0533": { "p_correct": 0.31 }
},
"model": "kt-2026-07"
}Built like measurement infrastructure, because it is.
Calibration is the headline metric
A mastery estimate of 0.8 should be right about 8 times in 10. We optimize and report calibration first, alongside AUC, and every prediction ships with a confidence interval. If we cannot measure it honestly, we do not ship it.
Open, de-identified corpora
The knowledge-tracing model is trained on public datasets such as ASSISTments. Evaluation numbers will be published against held-out data so you can check our claims before you build on them.
Stateless about who students are
You send opaque learner IDs; we never see names, emails, or demographics. Identity stays in your system, which keeps your FERPA and COPPA surface where it belongs.
REST first, SDKs next Planned
The REST API comes first. Thin SDKs for TypeScript and Python follow, along with a demo adaptive-quiz app you can read as a reference integration.
In development, in the open.
LearnState is being built right now by a small team. There are no customers to name yet and no metrics to brag about, and we would rather tell you that than invent some. Here is the near-term plan:
- Reproduce a strong knowledge-tracing baseline on ASSISTments and publish the calibration numbers.
- Open the two-endpoint API to a first group of design partners.
- Ship the demo adaptive-quiz app as a reference integration.
Questions developers ask first
What exactly do I send you?
Response events: an opaque learner ID, an item ID, the skills the item touches, whether the answer was correct, and optionally response time. Item content (the question text) can be registered once so we can embed it; learner PII is never part of the API.
How is this different from asking an LLM to judge mastery?
An LLM judgment is a one-off guess with no error bars. LearnState runs a trained knowledge-tracing model over the learner's full practice trace and returns probabilities that are explicitly calibrated against held-out data, with confidence intervals attached.
Do I need my own skill taxonomy?
You can bring one, or start from item-to-skill mappings we help you bootstrap from item content embeddings. Skills are just string IDs to the API; the model learns their structure from your traces.
What about student privacy?
The API is stateless about identity by design: learner IDs are opaque tokens you mint, and we store only the practice trace attached to them. Training data is public and de-identified. When your app has FERPA or COPPA obligations, this split keeps identifiable data entirely on your side.
When can I use it?
The API is in development. Join the waitlist and say a sentence about your app; design partners get access first, help shape the event schema, and pay nothing during the pilot phase.
What will it cost?
Usage-priced per prediction call, with a free developer tier that is generous enough to build and demo on. Exact numbers will be published with the public beta, not before we can stand behind them.