"Adaptive learning" is one of the most overused phrases in education technology. Almost every platform claims it. Very few explain what it actually means under the hood, and that vagueness isn't an accident, a lot of "AI-powered personalization" in edtech marketing is closer to a rule like "show an easier question if the last one was wrong" than anything resembling a real statistical model of what a student knows.
We'd rather be specific, even when the specific answer is more modest than the marketing language suggests. This post explains what Bayesian Knowledge Tracing (BKT) actually is, how teloriva's implementation works, and, just as importantly, exactly what's live in our system today versus what's designed but not yet built. That second part is the part most companies leave out. We're not going to.
What "adaptive learning" usually means, and what it can mean
At its weakest, "adaptive" in edtech means a simple branching rule: get three questions wrong, see easier ones next; get three right, see harder ones. That's a real technique and it's not useless, but it's not modeling anything about the student, it's just reacting to a short recent streak.
At its strongest, adaptive learning means maintaining an actual probabilistic estimate of what a student has and hasn't mastered, updating that estimate with each new piece of evidence, and using it to make a genuinely informed decision about what to show next. Bayesian Knowledge Tracing sits in that second category, and it's been part of the intelligent-tutoring-systems research literature since the late 1980s and early 1990s (originating with work by Corbett and Anderson on cognitive tutors), it's not a new AI buzzword, it's an established, well-studied technique with a real statistical foundation.
BKT explained simply
Imagine a single skill or concept, say, "solving one-variable linear equations." BKT tracks one number for that skill, for that student: the probability that the student has actually mastered it, somewhere between 0% and 100%. Every time the student answers a question tied to that skill, BKT updates that probability using four parameters:
- Prior, how likely the student was to already know the skill before any evidence at all (a reasonable starting guess).
- Learn, how likely the student is to transition from "not knowing" to "knowing" the skill after a single practice opportunity.
- Guess, how likely the student is to answer correctly even if they don't actually know the skill (relevant for multiple-choice, where a lucky guess is possible).
- Slip, how likely the student is to answer incorrectly even though they do know the skill (a careless mistake, a moment of distraction).
Each answer becomes a small update to the mastery estimate, a correct answer nudges the probability up, an incorrect answer nudges it down, but crucially, the model accounts for guess and slip, so a single lucky guess doesn't spike a student's mastery estimate to 100%, and a single careless mistake doesn't tank it. It's a rolling, evidence-weighted belief about mastery, not a pass/fail count.
That's the general idea of BKT. In our system, the mastery service runs exactly this, a genuine Bayesian posterior update, with default parameters of a 0.20 prior, 0.20 guess probability, 0.10 slip probability, and 0.12 learn rate per practice opportunity. This isn't a simplified stand-in for BKT; it's the real posterior-update math, tagged internally with the model version hybrid_bkt_retention_v1.
Our specific model: BKT plus a retention-decay layer
Standard BKT has a well-known gap: it models learning during practice, but it doesn't model forgetting between sessions. A student who mastered a skill three months ago and hasn't touched it since is treated, in plain BKT, as if they still know it exactly as well as the day they last practiced.
We layer a custom exponential-decay retention model on top of the BKT mastery estimate to account for this. Alongside the mastery probability, the system tracks a "memory stability" value for each skill per student, essentially, how resistant that particular memory is to decay. Retention at any given moment is calculated as the mastery probability multiplied by an exponential decay factor based on how many days have passed since the student last practiced that skill, divided by that stability value. And the stability value itself isn't fixed, it grows when the student answers correctly (each successful review makes the memory a bit more durable) and shrinks when they answer incorrectly. In practice, this means a skill you mastered and have kept refreshing is treated as genuinely durable, while a skill you mastered once and haven't touched since is correctly flagged as fading, even though the original mastery estimate hasn't technically changed.
There's a third layer on top of that: when a student attempts the same practice section repeatedly, later attempts count for progressively less in the mastery calculation, each additional attempt on the same content is weighted at 0.7 times the weight of the one before it, down to a floor of 0.2. This exists so that a student who just brute-forces the same exercise ten times in a row doesn't get an inflated mastery score purely from repetition; genuinely varied evidence counts more than repeated grinding on one item.
To be precise about what this is and isn't: this is real, working adaptive-learning mathematics, a genuine Bayesian posterior update combined with a custom retention-decay model, not a neural network, not deep knowledge tracing, and not item response theory. It's a specific, honestly-named statistical model, and "Bayesian Knowledge Tracing plus a custom retention-decay layer" is exactly what it is.
Skills don't exist in isolation: the concept graph
Mastery estimates for individual skills only get you so far, most real learning objectives depend on multiple prerequisite concepts, and struggling on one often traces back to a shakier foundation elsewhere. Our system models this explicitly: concepts are connected by dependency edges (prerequisite, supporting, or interfering relationships), forming a real knowledge graph rather than a flat list of topics. Each learning objective in a course is built from a weighted combination of underlying concepts, with a default mastery threshold of 95% and a default retention threshold of 80% before an objective is considered solidly learned. This structure is what lets the system reason about why a student is struggling, not just that they are, pointing back toward a specific prerequisite rather than just serving up another question on the same topic.
What decides what a struggling (or thriving) student sees next
Mastery and retention estimates feed into a routing decision every time a student moves to their next step. The routing engine scores a set of candidate next actions, continue on, get a hint, review a prerequisite, get a targeted remediation exercise, skip ahead if already mastered, get a harder challenge, or (with genuine chronic struggle) get escalated to the teacher, and picks the highest-scoring one. Every candidate's score is saved, not just the winning choice, so the full reasoning behind a routing decision is auditable after the fact, not a black box.
Worth calling out specifically: the system supports a genuine "shadow mode," where routing decisions are fully scored and logged exactly as they would be live, but never actually shown to a student. That's a real engineering-maturity feature, not a marketing line, it means new or adjusted routing logic can be tested safely against real student data before it's ever allowed to change what a student actually sees.
Full disclosure: what's live today, and what isn't (yet)
Here's the part most companies bury in a footnote, and we're putting it front and center instead, because we think this kind of specificity is exactly what should separate a credible engineering-led education company from one that's just using the right buzzwords.
The routing decisions above are made by a policy, a pluggable, swappable piece of logic that scores the candidate next steps. Our system is architected to support multiple interchangeable policies, and there are four policy files in the codebase today, that's not the same as four working policies, as the breakdown below makes clear. Here is exactly where each one stands:
GuardedHybridPolicyV1, live today, and the only policy actually running. This is a deterministic rules-and-heuristics engine that scores every candidate next step directly from a student's real mastery and retention estimates (the BKT-plus-retention-decay numbers described above), their misconception history, and their attempt history. It's the one policy actually registered and used for every routing decision the platform makes right now, and it's also the automatic fallback for any policy key the system doesn't recognize. Every claim in this article about mastery-driven routing describes what this policy actually does.- A contextual-bandit policy (
LinUCBPolicy), not built. This exists in the codebase as a stub. Calling it raises an unimplemented-method error immediately; there's no trained model behind it, and nothing in the platform calls it. - A deep knowledge tracing policy (
DKTPolicy), not built. Same situation: a stub file with no working implementation and no neural-network code behind it anywhere in the codebase. - A reinforcement-learning policy (
RLPolicy), not built. Same pattern again, an unimplemented placeholder, not a working system.
So, plainly: we do not currently run a contextual bandit, deep knowledge tracing, or reinforcement-learning personalization system. If you've seen those terms in other platforms' marketing, that's a fair thing to ask about directly, ask what's actually scoring decisions in production, not just what's listed on an architecture diagram. In our case, the honest answer is one deterministic policy built on real Bayesian Knowledge Tracing mastery data, with three additional slots in the architecture that are ready to be filled in as those techniques are actually built and validated, not as a promise dressed up as a feature.
We think this is worth stating this directly, because the alternative, implying three sophisticated machine-learning systems are quietly running in the background when they're not, is exactly the kind of overclaim that makes teachers reasonably skeptical of "adaptive learning" marketing in the first place. The pluggable architecture is a real, genuine engineering choice (a string-keyed policy registry, a model for future trained artifacts) that makes adding real bandit or deep-learning-based policies possible down the line without rearchitecting the system. It's an honest roadmap, not a hidden gap.
Why this level of specificity is the point
A lot of "adaptive learning" marketing is designed to sound impressive without being falsifiable, vague enough that no one can check whether "AI-powered personalization" means a genuine statistical model or an if-statement. We'd rather you be able to check. Bayesian Knowledge Tracing is a real, named, decades-old technique with real math behind it, our retention-decay layer is a specific and describable extension of it, our concept graph is real structure connecting skills to each other, and our routing engine is one specific, working, auditable policy today, with three more slots in the architecture clearly labeled as not yet built, rather than quietly implied to exist.
If you want to see how this connects to the rest of the platform, spaced repetition, gamification, and the classroom-level teaching runtime, that's covered in the Adaptive Learning Engine section of the teloriva platform overview.
Meta title: Bayesian Knowledge Tracing, Explained for Teachers | teloriva Meta description: What Bayesian Knowledge Tracing actually is, how teloriva's hybrid BKT + retention-decay model works, and which adaptive policies are live today.