B.Tech · 20 September 2026 · 7 min read

The specific bars behind Kalvium's Excellence layer

Excellence at Kalvium isn't graded, but it isn't vague. Here are the actual thresholds: 8 weeks of real users, 10+ merged pull requests, three juniors mentored, and why the bars are set that way.

The specific bars behind Kalvium's Excellence layer
In this article

I wrote about the Excellence layer once already, and by the end of that piece I still owed the reader one thing: what actually counts.

The earlier post made the case for why a degree needs a third layer beyond the AICTE-compliant core and the employability track. It leaned on Etienne Wenger’s research on communities of practice, the idea that becoming an expert is inseparable from becoming a recognised contributor to a practice outside the classroom. That argument still holds. But it was a philosophy piece. It named four kinds of contribution in general terms: owning a product, contributing to open source, mentoring, writing. It never told you how much of any of them counts.

I went back to the source material to close that gap, and it turns out the bars are specific. Not vague aspiration. Actual thresholds. I’ll admit I didn’t expect them to be this concrete.

The five categories, with the numbers attached

Kalvium’s programme documentation lists Excellence under five named categories, each with a defined bar rather than an open-ended description.

Product Ownership at Scale. Build, launch, and sustain a product with real users for at least 8 weeks, incorporating documented user feedback. Not a weekend hackathon build. Not a demo that works once in front of a mentor. Eight weeks, minimum, with users who aren’t classmates doing a favour, and a record of feedback that shaped the product along the way.

Engineering Influence. Publish deep technical essays on system design, architecture, or engineering tradeoffs, with demonstrated external readership or citations. The bar here is external attention, not word count. A well-written essay nobody outside the programme reads doesn’t clear it.

Serious Open-Source Impact. Achieve 10 or more merged pull requests, or ownership of a module or feature, in a recognised open-source project with maintainer review. One accepted patch is a start. Ten merged pull requests, reviewed by a maintainer who has no obligation to accept them, is a different kind of evidence.

Mentorship & Leverage. Mentor at least three juniors over a semester, with measurable improvement in their outcomes. A single good conversation with a struggling junior isn’t this. A semester of sustained mentoring, with something to show for it in the junior’s own progress, is.

Ethical & Social Impact. Design and deploy a tech solution used by a real community, NGO, or institution, with measured social outcomes. This is the category the earlier post didn’t cover at all, and it’s worth sitting with. It asks for the same evidentiary standard as the other four: a real deployment with a measured effect, aimed at a beneficiary outside the tech industry entirely.

None of the five is examined. None affects degree graduation. All five are optional, and the programme’s explicit that participation is intentionally high-bar. That framing matters, because a bar this specific only makes sense if it’s meant to be genuinely hard to clear, not a box every student is expected to tick.

Why the bars are duration and count, not talent

Here is the design question worth asking: why measure Excellence in weeks and pull-request counts at all? Why not just ask a mentor to judge whether a student’s contribution is “good”?

The honest answer is that a single strong moment tells you very little about whether a student can sustain the work once the initial motivation wears off. A brilliant weekend project proves talent for a weekend. Eight weeks of real users, with documented feedback along the way, proves something talent alone doesn’t: that the student kept going through the parts that weren’t exciting, fixed the bugs nobody was watching, and stayed responsible to people who were actually depending on the product.

There’s a specific finding in psychology that names this distinction directly. Angela Duckworth spent years studying why some people achieve more than others with similar, or even lesser, raw ability. She looked at contexts as different as a military academy’s punishing first summer and the National Spelling Bee. Her research, most widely known through her 2016 book on the subject, defined grit as a combination of two things: passion for a long-term goal, and perseverance in pursuing it despite setbacks and plateaus. Across her studies, grit predicted who finished what they started better than measures of talent or intelligence did on their own.

That finding maps onto Kalvium’s Excellence bars almost exactly. Ten merged pull requests isn’t a talent threshold. Most of the students capable of writing one excellent pull request are capable of writing ten. The real filter is whether they kept submitting. After a maintainer requested changes. After a pull request got rejected. After the ninth one felt less exciting than the first. Three juniors over a semester isn’t a mentoring-skill threshold either. Plenty of students can give one junior good advice once. Fewer show up consistently enough, across a full semester, for three different people to have measurably improved because of it.

Read this way, the specific numbers aren’t arbitrary administrative detail. They’re the mechanism. If the bar were “make a meaningful open-source contribution,” a single lucky merge would satisfy it, and the layer would end up measuring a moment rather than the quality Duckworth’s research says actually predicts sustained achievement.

What this changes for a student deciding where to spend time

So where should a first-year student actually start?

If you’re reading the five categories and wondering where to spend real time, the honest answer is that the easiest mistake is chasing the wrong kind of “impressive.”

A flashy weekend build that never gets a second user does not touch Product Ownership at Scale, no matter how good the demo looks. One clever pull request into a well-known repository does not touch Serious Open-Source Impact either, even if it looks good on a resume screenshot. The bars reward a less photogenic version of the work. Think of the eighth week of maintaining a product nobody’s watching closely anymore. The fifth pull request after a maintainer has already pushed back twice. The mentoring conversation you have with a junior in week 10, once the novelty’s worn off for both of you.

That’s also, not coincidentally, the part of any real engineering job that a resume can’t fake. A hiring manager reading “10+ merged pull requests, maintainer-reviewed” is reading evidence of exactly the kind of follow-through Duckworth’s research says predicts whether someone finishes what they start. It’s a different, and arguably more useful, signal than a single polished project.

Where the evidence gets thin

I want to flag the limits of the Duckworth frame honestly, the same way I try to with every research claim I make in this lane.

Here’s the pushback worth knowing about. Grit research has drawn real criticism within psychology. Some replication attempts found the effect on academic and professional outcomes was smaller than Duckworth’s original studies suggested, particularly once you control for conscientiousness, a personality trait grit overlaps with substantially. The finding that sustained effort over time correlates with achievement isn’t seriously contested. How much of that correlation is a distinct “grit” factor, versus a restatement of already-known personality traits, is a genuinely open question in the field.

What I can say without hedging is narrower, and I think still useful. Whatever you call the underlying trait, a threshold measured in weeks and pull-request counts selects for people who kept going, in a way a threshold measured in “quality of the best thing you made” doesn’t. Kalvium’s Excellence bars are a bet on that distinction. They aren’t a claim to have settled the academic debate about what grit is or how much of it can be taught.

The layer in context

Excellence sits alongside two other layers that are graded and examined very differently. Essentials is the AICTE-compliant core, assessed through university exams. Mastery is the employability layer, verified through codebases, deployments, and real artifacts rather than written tests. Excellence, covered here, is the only one of the three that is fully optional and never touches the degree. For the fuller build arc that produces the raw material a student would actually use to clear any of these five bars, see what a Kalvium student builds in four years.

Essentials shows what a student studied. Mastery shows what they are ready to do. Excellence, with these specific bars attached, shows what they were willing to keep doing after the interesting part was over.


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.

Frequently asked questions

What are the five categories in Kalvium's Excellence layer?

Product Ownership at Scale, Engineering Influence, Serious Open-Source Impact, Mentorship & Leverage, and Ethical & Social Impact. Each has its own bar. Product Ownership at Scale needs at least 8 weeks with real users and documented feedback. Engineering Influence needs published technical essays with demonstrated external readership or citations. Serious Open-Source Impact needs 10+ merged pull requests or ownership of a module or feature in a recognised project. Mentorship & Leverage needs at least three juniors mentored over a semester with measurable improvement in their outcomes. Ethical & Social Impact needs a deployed tech solution used by a real community, NGO, or institution, with measured social outcomes.

Is the Excellence layer graded or required to graduate?

No. Excellence sits outside the AICTE-compliant Essentials layer and does not affect degree graduation. It is optional and intentionally high-bar. A student can complete the B.Tech in full without ever pursuing an Excellence-layer bar.

Why does Kalvium set duration and count thresholds instead of just asking for good work?

Because a single good week, one merged pull request, or one useful conversation with a junior does not tell you much about whether a student can sustain effort once the initial motivation fades. The specific bars, at least 8 weeks, 10+ pull requests, a full semester of mentoring, are built to filter for sustained contribution rather than a single strong moment. That matches what psychologist Angela Duckworth's research on grit has found: passion and perseverance toward a long-term goal predicts achievement more reliably than short bursts of talent.

How is this different from Kalvium's Mastery layer?

Mastery asks whether a student is ready to do the work of a software engineer, verified through codebases, deployments, and real artifacts, assessed at milestone checkpoints. Excellence asks what a student has actually sustained over time, with a stake outside their own coursework: real users for two months or more, a body of accepted open-source contributions, a semester of mentoring someone junior. A student can be strong on Mastery without having started on Excellence. They test different things.

Can a first-year Kalvium student work on Excellence-layer contributions?

Yes. Excellence runs across all four years and is not linked to a specific semester or subject. The bars themselves, particularly Serious Open-Source Impact and Engineering Influence, are realistic starting points once a student has enough foundational skill, which for most students builds through the first two semesters of full-stack work.