StudyNova: a study tool that shows its sources, built at HackUMass XIV

Priyanka P — Sun, 15 Nov 2026 12:24:46 +0000

This is a submission for the MLH x DEV Writing Challenge.

What I Built

At HackUMass XIV, the three of us built StudyNova, a study tool that uses only your own course materials and lets you trace every piece of information back to its source.

The problem is something most students can relate to. Lecture slides are stored in one place, PDFs in another, and recordings somewhere else. When it is time to prepare for an exam, you end up going through all of them again. Even when you get a practice question wrong, it is not always clear what went wrong. Sometimes the problem is not the concept in the question itself, but an earlier topic that you never fully understood. Most AI study tools do not make this any easier. They give you answers, often confidently, but rarely show you how to verify them.

StudyNova brings together the slides, PDFs, web pages and lecture recordings you already have and uses them in four ways:

Maps the important concepts and their dependencies, with a supporting page reference for every connection.
Quizzes you using your own course materials, with a citation attached to every question.
Traces incorrect answers back through the prerequisite concepts to identify what you are most likely missing.
Plans your revision based on those gaps, giving more weight to concepts that appear frequently in your past exams.

If a question cannot be answered using your uploaded materials, StudyNova tells you that the information is "not in your materials" rather than making something up.

Demo

Live site: studynova.ink. The landing page explains the application, while the actual workspace is accessible through a team login.
Video: {https://youtu.be/FAQxpiCUJQs}
Code: github.com/Priyanka-Purushotham5/studyweave

![The StudyNova concept map: concepts shown as stars, coloured by readiness]

![After a wrong answer, a gold path leads to the likely gap, Chain rule, with the quote from the lecture slides]

One interaction captures what we wanted StudyNova to do. Imagine answering the question, "Which rule does backpropagation apply layer by layer?" with Product rule. StudyNova marks the answer incorrect and traces the prerequisite links backwards, highlighting Chain rule in gold as your weakest prerequisite. Alongside the highlighted concept, it shows the exact sentence from your Lecture 7 slides that explains the rule. The revision plan then moves Chain rule to the top of your study list.

![The revision plan, with Chain rule first]

How it works

We divided StudyNova into three modules, with one person responsible for each and a strict, one-way communication flow:

Browser (web app + Chrome extension)
              |
              v
API (Node, MongoDB Atlas)
              |
              v
AI service (Python, Gemini)

The browser communicates only with the API, which in turn communicates with the AI service. The AI service is stateless and is the only component that makes calls to Gemini.

We started with the contracts. During the first few hours, we defined every JSON structure that would pass between the modules using JSON Schema. We also created a small demo module in fixtures/. Each person could then develop independently against a mock of the neighbouring module, using those fixtures. The AI service had a fake Gemini client, the API had a fake AI client, and the web app used mock handlers. This meant nobody had to wait for another person to finish their part before getting started. We also configured CI to validate every fixture against its corresponding schema on each pull request.

Every quote is verified in code. This is probably the part of the project I am most proud of. Whenever the model generates a concept, a connection between concepts or a question, it also provides a supporting quote and the page where that information appears. Before anything is shown to the student, the AI service checks whether the quote actually exists on the specified page. The check accounts for differences in case, whitespace, curly quotation marks and hyphenated line breaks. Anything that cannot be verified is discarded and counted rather than displayed.

Recent attempts have more influence on readiness. For each concept, we calculate readiness by giving more weight to recent attempts. The latest attempt is considered first:

R_{c} = 100 \times \frac{\sum _{k} 0. 8 ^{k} a _{k}}{\sum _{k} 0. 8 ^{k}}

Here, $a_{k}$ is 1 for a correct answer and 0 for an incorrect one. For example, a sequence of right, wrong, right gives a readiness score of 67.

Revision priority is calculated as:

priority = exam weight \times (100 - readiness)

Exam weight represents the number of past papers in which that concept appears.

The gap trace is deterministic. Instead of asking the model to guess why a student got something wrong, we follow the prerequisite links backwards and identify the weakest ancestor concept. A concept is labelled "likely gap" if it has at least two attempts and a readiness score below 40. Otherwise, it is labelled "possible gap". We deliberately avoid claiming that we know the exact reason behind a wrong answer.

Lecture captions use the same terminology as the slides. To improve transcription accuracy, we build a glossary from the lecture slides and pass it to the transcription process. We then use fuzzy matching to flag likely transcription mistakes, such as "back propagation" being recognised instead of "backpropagation". If a student corrects the same word twice, that correction is applied automatically the next time.

Partner Technologies

Google Gemini API: Used for concept extraction, prerequisite links, question generation, grounded answers, past-paper tagging, 768-dimensional embeddings and lecture transcription. All Gemini calls go through a single client file with a fake counterpart, so tests can run without an API key.
MongoDB Atlas: Stores subjects, modules, resources, concepts, attempts and readiness scores.
Vultr: The complete application runs in Docker on a Vultr Ubuntu server, with Caddy handling HTTPS.
GitHub Actions: Runs the AI service, API, web, sign-in and contract tests on every pull request.

Hackathon Experience

What went well.

Starting with clearly defined contracts was probably the best decision we made. All three of us could work in parallel from the first few hours, and when the API was connected to the actual AI service for the first time, the data structures already matched. We did not have to spend time fixing integration issues caused by different assumptions about how the modules should communicate.

What surprised us.

A test that passed with mocks failed against the real API. Mock responses arrive immediately, but the actual API takes a little time to respond. Our browser test was reading the next question before it had finished loading, which meant it ended up answering the wrong question. After logging every request, we found that the question displayed on screen and the question ID being submitted were off by one.
Our animations caused problems during the accessibility audit. Text that fades in briefly has lower contrast while the animation is running, which axe flagged. We replaced the text fade-in animations with slide animations so that the text remains at full contrast throughout.
Gemini model availability changed during the hackathon. New AI Studio keys now use a new "AQ." format. One of the models available in our key's model list returned a message saying it was no longer available to new users, while two others timed out under the weekend's load. We wrote a probe script to check model availability and added fallback support so that requests could switch models while staying within the API's 60-second limit.

What the first live run showed.

On a three-page sample lecture, the live Gemini pipeline kept all 6 concepts it found, generated 36 questions, answered an in-scope question with citations, and refused an off-topic one with "not in your materials". 42 of 43 generated items passed the quote check (97.7%); the one that failed was dropped before reaching the student. That is a small sample, so we will be measuring it on full lectures next.

What I learned.

An AI feature is only as trustworthy as the checks built around it. Choosing not to display something that cannot be verified might mean covering a little less information, but it goes a long way towards building trust.

Designing for readers who struggle with reading

We built StudyNova for the Accessibility track, so readability was something we considered throughout the design rather than adding at the end.

Night sky, not pitch black. We chose a deep navy background with warm off-white text instead of pure white on black, whose glare many readers with dyslexia find hard to read.
Colour is never the only indicator. Every readiness state has both an icon and a label: ○ Untested, ! Weak, ◐ Developing, ✓ Strong and ★ Cleared.
Multiple reading options. The application includes a readable mode with increased letter, word and line spacing, a high-contrast mode and a keyboard-accessible outline of the entire concept map.
Motion can be turned off. The concept map draws itself like a constellation, while the gap path flows in gold. Both the operating system's reduced-motion setting and an in-app toggle can disable all animations and display the final state directly.

What's next

Measure the citation pass rate and transcription accuracy using full lectures and real recordings, and publish the results.
Introduce individual student accounts instead of relying on the shared team login used in the hackathon version.
Complete a full screen-reader accessibility audit using NVDA and VoiceOver.

Built by Priyanka Purushotham (AI service), Danush Kanchi (API, data and deployment) and Rohith Bangalore Vijaya (web app and Chrome extension) at HackUMass XIV, University of Massachusetts Amherst.

DEV Community: Priyanka P