Here’s a question that took me a while to sit with properly: what does a degree actually certify once you strip away the exam and the job offer?
Most of the time we answer that question with the first two layers of our own curriculum, and stop there. Essentials tells you a student studied the right things. Mastery tells you a student can do the work, verified through codebases and deployments rather than written tests, as I’ve written about before. Between the two, you have a graduate who knows the fundamentals and can ship working software. That sounds like the whole story. It isn’t.
There’s a third layer at Kalvium, and it’s the one I find hardest to explain cleanly. It isn’t measured the way the other two are, and its payoff is deliberately slow. It’s called Excellence, and it isn’t coursework. It’s earned.
What Excellence actually is
The curriculum guide describes it plainly: Excellence prepares students for long, evolving careers in technology, not for the first job alone. It’s earned, not completed, through owning products used by real users, contributing at scale to open-source projects, mentoring peers and juniors, and publishing deep technical writing. There’s no syllabus for it and no exam.
That’s a strange thing for a degree programme to include, and I want to be honest about why it’s there rather than gesture at it vaguely.
Essentials and Mastery both describe a starting line. Essentials says: this student has the fundamentals. Mastery says: this student can build real software under real conditions. Both are necessary. Neither one tells you whether a student has started the slower work of becoming someone whose output other people actually depend on. Whose name shows up in commit histories other engineers read. Whose written explanation of a hard idea gets used by someone who has never met them. That kind of contribution doesn’t show up on a transcript or in a deployment log. It shows up over time, in a public record. Excellence is the layer built to hold that record.
The research behind why “ownership” is the right frame
This is the part of the research I find most useful, and it isn’t about individual skill at all.
The clearest research frame I have for this comes from Etienne Wenger, a learning theorist who spent much of his career studying how people actually become experts in a field. He built on earlier collaborative work with Jean Lave in the late 1980s and early 1990s.
Their central claim, developed through studies of apprenticeships across very different trades, was that becoming skilled at something isn’t primarily an act of individual knowledge accumulation. It’s a process of becoming a recognised, contributing member of a community that already does the work. Wenger called these groups communities of practice. The mechanism he described, legitimate peripheral participation, is the idea that newcomers become experts by doing real work at the edge of a practice. That work genuinely matters to the community even while it’s still small in scope. Standing grows gradually, and with it comes more central, higher-stakes contributions.
That’s a meaningfully different claim from “practise until you’re good.” It says expertise is inseparable from participation in a community that recognises your work as real. A merged pull request into a project other engineers maintain isn’t just a coding exercise. It’s a small act of legitimate peripheral participation, work a real community accepted as genuinely useful. Mentoring a junior is the same pattern read from the other side, moving from peripheral participant toward someone whose judgement other people in the practice now rely on. Technical writing that people outside the programme actually read is a public claim to standing in a community of engineers, tested by whether that community finds it useful.
Read this way, Excellence isn’t a bolt-on “extracurricular” category. It’s an attempt to build the exact mechanism Wenger and Lave describe inside a four-year programme. People become engineers in the fullest sense through sustained, recognised contribution to a practice that exists outside the classroom.
Why this cannot be examined the way Essentials is
The measurement problem here is even sharper than it is for Mastery.
A written exam can test whether you understand a data structure. An artifact-based assessment, the kind Mastery uses, can verify whether a system you built actually runs. Neither can verify whether a community of practice has recognised your contribution as real, because that recognition isn’t something the programme grants. It’s something the outside world grants, on its own terms and its own timeline. An open-source maintainer merges your pull request or doesn’t. A junior remembers something you taught them or doesn’t. A reader finishes your technical essay and uses it or doesn’t.
That’s precisely why Excellence sits outside the formal degree structure. It’s the same design logic that keeps Mastery outside the exam system, taken one step further. You can’t grade participation in a community of practice on a fixed academic calendar. The community doesn’t operate on that calendar, and it doesn’t owe the programme a verdict by a deadline. What the programme can do is create the conditions: time, mentorship, and Semester 3 onward work tracks like open-source contribution. That’s where the participation becomes possible, for a student who chooses to pursue it.
What this means in practice
If you’re a student reading this and wondering what to actually do about it, the honest answer is that Excellence rewards a different instinct than the one coursework trains.
Coursework rewards finishing what’s assigned. Excellence rewards starting something nobody assigned you and sustaining it long enough that it becomes real to someone else. That could be a small open-source contribution that grows into repeated, trusted involvement in a project. It could be mentoring a junior in your squad seriously enough that they’d say it mattered, not just showing up once. It could be a piece of technical writing precise enough that another engineer, a stranger, finds it and uses it to solve their own problem. The curriculum guide is explicit that these examples aren’t exhaustive: it lists them “and more.”
What they share is the external stake. Coursework is complete when you submit it. Excellence-track work isn’t complete until someone outside your own transcript has actually used it, relied on it, or learned from it.
Where the evidence gets thin
I want to be honest about the limits of the research frame here, the same way I try to be with every learning science claim I make in this lane.
Wenger and Lave’s work on communities of practice was developed largely by observing apprenticeship structures in trades like tailoring and midwifery, not software engineering specifically. It also wasn’t developed inside a four-year degree programme with a formal Essentials and Mastery layer running alongside it. The core mechanism, that expertise is built through recognised participation in a practice rather than solitary skill accumulation, has held up well and gets cited across professional education research since. Whether a structured curriculum layer can reliably produce the same effect that emerges naturally in an apprenticeship, where the stakes and the community are given rather than constructed, is a genuinely open question. We’re building the conditions for it. We aren’t claiming to have proven the mechanism transfers cleanly into a programme design.
What I can say without hedging is the shape of the claim. A degree that only certifies what you studied and what you can build stops short of something important. It stops short of becoming someone whose work a community of practitioners has come to rely on. That’s a slower thing to earn than a grade, and it doesn’t fit inside an exam. It’s worth having a layer that tries anyway.
The three layers together
Essentials shows what a student has studied. Mastery shows what a student is ready to do. Excellence shows who a student became.
None of the three substitutes for the others. A student who only pursues Essentials and Mastery graduates genuinely capable and employable, and that’s not a small thing. But the record that follows someone across fifteen years in technology is rarely the transcript or even the first deployed system. It’s closer to the open-source history, the people they mentored who went on to do good work, the writing that other engineers still reference. Excellence is the layer aimed at building that record deliberately, starting in Year 1 rather than waiting for a career to force the habit.
For the fuller argument on why Mastery is verified through artifacts rather than exams, see why Kalvium’s most employable skills are kept out of your exams. And for the study habits that make any of these three layers stick rather than fade, see learning how to learn for real engineering, not for exams.
Arvind is Head of Programme Design and Delivery at Kalvium. He writes about the cognitive science of learning and how it shows up in the design of a live programme. He’s grounded in named research and honest about where the evidence is still being worked out. Read more from Arvind or browse the B.Tech category.