Ask about HEROS and you’ll get one answer. Ask about Live Books and you’ll get a different one. Ask about DOJO and you’ll get a third.
All three answers are correct. All three, read separately, miss the actual design decision.
Each of these systems has its own homepage description, its own explainer post on this blog, its own specific job. Read them one at a time and Kalvium looks like a programme with three useful features bolted onto a curriculum. That’s not wrong, exactly. It’s incomplete. The constraint we actually built against wasn’t “how do we build three good systems.” It was “how do we make three specialised systems behave as one pipeline without slowing any of them down individually.”
The three jobs, stated plainly
Start with what each system actually produces, because the differences matter.
DOJO is daily coding practice. A student solves timed problems in Python, JavaScript, Java, and C++. There’s a belt structure, six belts per language, each earned through a test rather than assumed through attendance. What DOJO produces, every single day, is a signal: which belt a student’s working toward, which problem types they’re failing, how many attempts a specific problem took before it landed.
Live Books is the curriculum layer. Digital learning guides that update as the industry changes, and that capture real work: projects, assignments, quizzes, hands-on tasks. What Live Books produces isn’t a daily pass or fail. It’s an evolving artifact. A student’s Live Books record from Semester 1 to Semester 4 is a portfolio in progress, milestone by milestone, not a single test score.
HEROS is the third piece, and its job is different in kind from the other two. HEROS doesn’t produce daily practice data and it doesn’t produce project artifacts. It continuously monitors student learning and progress, identifies gaps early, evaluates performance using clear and consistent criteria, and tracks learning activity across every session and milestone. Read that last function carefully. It says “across every session and milestone,” not “in its own sessions.” HEROS’s job is to read what the other two systems are already producing.
The option we didn’t take
There was a simpler version of this we considered and rejected: one system that handled daily practice, project tracking, and gap monitoring together, end to end.
The appeal is obvious. One system to build. One system to maintain. One dashboard.
The problem is rhythm. Daily coding practice needs an immediate feedback loop: a student attempts a problem, the system tells them pass or fail within the session, and that’s it. Project work runs on a completely different clock. A Live Books milestone might take two weeks to build. Grading it the same way you’d grade a DOJO problem, instantly and mechanically, would either oversimplify the project work or slow the whole system down trying to handle both rhythms at once. Gap monitoring is different again. It doesn’t need to be fast in the way DOJO does. It needs to be continuous, running quietly underneath both of the other two, watching for patterns that only show up when you look across sessions rather than within one.
A single system built to do all three jobs at once ends up compromising on all three. The daily-practice loop gets slower because it’s now coupled to a heavier gap-monitoring process. The project-tracking layer gets flattened into pass/fail logic that doesn’t fit multi-week work. And the gap-monitoring layer, instead of quietly reading two clean data streams, has to untangle its own signal from inside a system that’s also trying to be a practice tool and a portfolio tracker.
Three specialised systems, each built for its own rhythm, and one shared layer that reads across all three: that’s the design that survived. Not because three systems is inherently better than one. Because the three jobs genuinely don’t run on the same clock, and forcing them onto a shared clock costs more than it saves.
What the pipeline actually looks like in practice
Here’s the mechanism, stated as plainly as I can put it.
DOJO produces a daily signal about a specific, narrow kind of competence: can this student solve this class of problem, under test conditions, right now. Live Books produces a slower, richer signal about applied work: what did this student build, does it meet the milestone, how does this compare to what they built last time. Neither signal, on its own, is the full picture. A student can be strong in DOJO and stall on a Live Books milestone. A student can ship solid project work and be quietly stuck on a specific problem type in DOJO that hasn’t yet shown up anywhere else.
HEROS is the layer that reads both streams together, across every session and milestone, and turns two separate signals into one usable pattern. When a student’s DOJO attempts on a problem type start failing repeatedly, or a Live Books milestone comes in late or thin, that’s activity HEROS is already tracking. The pattern doesn’t need to wait for a semester-end exam to become visible. It surfaces while there’s still time for a mentor to do something about it.
That changes what a mentor conversation looks like in a concrete way. Without the pipeline, a mentor check-in is a general welfare question: how’s it going, anything you’re stuck on. With the pipeline, the mentor’s arriving at that conversation already knowing where the specific gap is. The conversation starts at “I can see you’ve attempted this problem type four times this week, what’s happening there” instead of starting from zero. That’s a structurally different conversation, not a faster version of the same one.
What this doesn’t claim
Worth being precise here, because it’s easy to overstate what a monitoring pipeline does.
The pipeline surfaces a specific category of signal: patterns in graded and gradable activity across every session and milestone. It isn’t a claim that every kind of student difficulty gets caught. A student who’s struggling with something outside what DOJO and Live Books track won’t show up in this particular pipeline, and the honest answer is that no system catches everything. It also isn’t a promise about outcomes. What the pipeline does is make one category of struggle visible earlier than a periodic-exam model would make it visible. What happens after that visibility, whether a mentor’s intervention lands, whether a student engages with the support offered, is still down to the people in the room.
It’s also worth separating this pipeline from Autonomous Learning, the fourth named system at Kalvium. Autonomous Learning is deliberately kept outside graded tracking, for reasons closer to motivation than measurement. HEROS, Live Books, and DOJO are the operational pipeline for gradable activity. Autonomous Learning runs alongside it, not inside it, and that’s a separate design decision with its own reasoning.
The question worth asking any programme
If a college tells you it has a “tech-enabled monitoring system,” one question actually separates a real pipeline from a marketing line. What happens to the data after it’s produced?
A system that logs daily practice scores but nothing reads them for patterns is a feature. A system that tracks project submissions but doesn’t connect them to anything else a student is doing is also a feature. A pipeline is different. It’s what you get when the output of one system becomes the input to another, and something changes as a result. Specifically: a mentor gets a signal they wouldn’t otherwise have had, at a point where it’s still useful.
For how HEROS specifically earned outside recognition for this monitoring function, what a Ministry of Education recognition means covers the Bharat Bodhan AI Conclave 2026 story. For how the mentor and squad structure uses this signal day to day, how Kalvium’s mentor and squad system is designed to catch problems early walks through that layer. For the broader curriculum decisions this pipeline sits inside, how we designed the B.Tech CSE curriculum covers the tradeoffs, and the complete guide to Kalvium for families has the full picture.
That’s the distinction we built HEROS, Live Books, and DOJO around. Not three good systems sitting next to each other. Three systems that were designed, from the start, to feed a fourth thing none of them are individually: a signal a mentor can actually act on.