I Built PROOF for a Friend Who Was Studying, But Not Actually Understanding

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built
I built PROOF for a friend who was studying Operating Systems.
He was doing something I think a lot of students do. He could read the notes, recognize the terms, and sometimes answer questions correctly. But when he had to explain the idea without looking at the notes, things became much harder.
That made me think about a simple question:
How do you know that you actually understand something?
That is why I built PROOF.
The idea is simple:
Don't tell me you understand it. Prove it.
PROOF doesn't just give another explanation or another quiz.
It asks the student to explain something from memory, looks for a weak part in the explanation, challenges that part, helps the student fix it, and then asks them to try again.
The main flow is:
Explain → Challenge → Repair → Verify
The Problem I Built It For
My friend was studying virtual memory and page faults.
He had a simple idea in his head: a page fault happens when RAM is full.
It sounds reasonable at first.
The problem was that it wasn't the complete explanation.
So I made PROOF hide the notes and asked him to explain the concept himself.
After looking at the explanation, PROOF found the assumption and asked:
“Suppose a program with 32GB of empty RAM reads its first variable. Why does the CPU still trigger a Page Fault?”
That question changed the conversation.
It showed that knowing the words wasn't enough. There was a missing part in the reasoning.
After trying PROOF, my friend said:
“It didn't let me get away with just saying 'it swaps to disk'. It caught the exact detail I was hand-waving.”
That was the main reason I decided to keep building the project.
I wasn't trying to make another big study platform.
I was trying to solve one problem I had actually seen.
How PROOF Works

1. Explain from memory The student doesn't see the reference notes. They explain the concept in their own words.
2. Find the weak part PROOF checks the explanation for things like: unsupported assumptions missing reasoning contradictions vague explanations hand-waving There is also a “What the Local AI Extracted” section so the student can see what was picked up from their explanation.
3. Challenge it Instead of simply saying that something is wrong, PROOF tries to challenge the weak point. For example, if the explanation depends on a certain assumption, the next question can change that situation and see if the explanation still works.
4. Repair it If the explanation breaks, the student can go back to the relevant study material and work on that specific gap. The goal is not to give them a huge answer. It is to help them fix the part they didn't understand.
5. Try again The student explains it again. If the reasoning holds up, the concept can become VERIFIED. So PROOF tries to separate two things: “I remember seeing this.” from “I can explain why this works.” Why I Made It This Way There are already many study tools that can explain topics, generate questions, make flashcards, and summarize notes. I didn't want to build another one of those. The problem I saw was different. Sometimes a student can get through a normal quiz because the question looks familiar. But change the situation slightly, and the misunderstanding becomes obvious. So PROOF focuses on that moment. It doesn't just ask: “Do you know the answer?” It asks: “Does your explanation still make sense when I challenge it?” The student also doesn't need to write a complicated prompt. The process is already built into PROOF. How I Built It I wanted PROOF to work locally as much as possible. The project has a common IAIProvider interface, which lets different evaluation and AI options work with the same application. The basic structure looks like this: Student Explanation ↓ PROOF Evaluation ↓ IAIProvider / | \ / | \ Local WebLLM Ollama Local evaluator PROOF has a deterministic local evaluator. It isn't an LLM. It provides a basic evaluation path without needing a model download, GPU, or cloud API. WebLLM PROOF can also use WebLLM to run an open-weight model in the browser. The model needs to be downloaded initially. After it has been cached, it can run locally. Ollama PROOF also supports Ollama, which lets a computer run supported open-weight models locally. Because these options use the same provider interface, I can change the model or provider without rebuilding the whole application. Keeping Study Data Local This part was important to me. A student might upload lecture notes or write explanations that they don't want sitting on some remote server. PROOF stores its main study data in the browser using IndexedDB. That includes things like: study material concepts explanations proof sessions The local AI options can also keep the model processing on the user's device. The deterministic evaluator can work without a network connection. For WebLLM, the first model download requires internet, but after the model is cached, it can run locally. I wanted to be clear about that instead of just saying “everything is offline.” Why Open Innovation Matters The open/local part of PROOF is useful because it gives me more control over how the project works. If I used only a closed cloud API, the simple approach would be to send every explanation to that service. With local inference, PROOF can process the student's material on their own device. It also means I can try different open-weight models without changing the whole application. For example, the project can use WebLLM or Ollama while keeping the main PROOF workflow the same. Another useful part is cost. When the model is running locally, there is no per-request cloud API cost. For a study tool that may be used frequently, that matters. What I Learned The biggest lesson from this project wasn't really about AI. It was about starting with a real person instead of starting with a feature. At first, I was thinking about making an AI study assistant. After talking to my friend, I realized that wasn't the actual problem. He didn't necessarily need another tool to explain Operating Systems to him. He needed a way to find out where his own explanation was wrong. That changed the project. The page-fault example also taught me something else: Sometimes one good question can reveal a misunderstanding much faster than a long explanation. That became the idea behind PROOF. Don't just explain the answer. Test the reasoning. Demo Live Demo:https://proof-phi-ten.vercel.app/