ConceptLens

Inspiration

Most educational tools only tell students whether an answer is right or wrong, but students rarely fail because they didn't study — they fail because they misunderstand one specific concept, and nothing in their workflow ever surfaces which concept, or why their reasoning went wrong. We wanted to build a tool that reads a student's actual reasoning, not just their final answer, and turns that into a targeted fix instead of a red X.

What it does

ConceptLens analyzes a student's answer and their step-by-step reasoning for a given question, and instead of just marking it right or wrong, it identifies the specific misconception behind an incorrect answer, whether that's confusing mitosis with meiosis or dividing only part of an equation by a constant, classifies the type of error as conceptual, procedural, an interpretation issue, or a logic error, explains exactly where the reasoning broke down, generates a short targeted "Quick Concept Fix" micro-lesson, and asks a follow-up question in a new scenario to check whether the concept actually generalized rather than whether the student can just repeat an answer. It also confirms and reinforces reasoning that's already correct, rather than only checking the final number. On the teacher side, every submission feeds a live dashboard showing which concepts a class is struggling with most, a breakdown of misconception types, and clusters of students who share the same underlying misconception even when they phrase it completely differently.

How we built it

The backend is Node/Express, using structured LLM prompts that force strict JSON output for both the initial diagnosis and the follow-up evaluation. Each submission is analyzed by an LLM to detect correctness, misconception type, concept label, and to generate a personalized micro-lesson and follow-up question. A library of micro-lessons is matched to each submission using embedding-based cosine similarity rather than simple keyword overlap, and recent submissions are embedded and clustered so the teacher dashboard can surface groups of students sharing the same underlying misconception across different phrasing. Supabase (Postgres) persists every submission and links it to its matched micro-lesson, powering both the student's follow-up loop and the teacher's aggregate dashboard. The frontend is built in React, with a student view for selecting a question, submitting an answer and reasoning, seeing live analysis results, and working through the follow-up loop, plus a teacher dashboard showing concept mastery stats, misconception distribution, and shared-misconception clusters.

Challenges we ran into

The LLM would describe the same concept slightly differently across calls, for example "correlation vs causation" versus "Correlation vs. Causation" versus "Confounding Variables vs. Correlation-Causation," which fragmented our dashboard stats into near-duplicate rows; we fixed this by matching each raw label against a fixed, canonical set of concept labels before aggregating. Our first version of misconception clustering also grouped all submissions by topic similarity, including ones where the student actually got the answer right, which meant the dashboard could misleadingly show several students sharing a misconception when some of them didn't have one at all, so we filtered clustering down to only incorrect submissions. We also found that our first embedding implementation reloaded the ML model from disk on every single request, adding several seconds of avoidable latency to each analysis, and fixed it by moving to a persistent embedding server that loads the model once, cutting embedding lookup time down to milliseconds.

Accomplishments that we're proud of

We're proud of building a diagnosis engine that correctly distinguishes actual misconceptions from valid-but-differently-phrased reasoning instead of just pattern-matching keywords, a teacher-facing clustering feature that surfaces shared misconceptions across a whole class rather than just per-student data, and catching and fixing real data-integrity bugs like concept label fragmentation and unfiltered clustering before they made it into the final product.

What we learned

We learned that structured JSON prompting is only half the battle, since the aggregation layer downstream, including dashboards, clustering, and stats, needs just as much care, as small inconsistencies in LLM output compound quickly at scale. We also learned that embedding-based semantic matching meaningfully outperforms keyword overlap for this kind of open-ended student reasoning, especially when the same misconception gets described in wildly different words.

What's next for ConceptLens

Next, we'd like to build a concept-prerequisite graph so a misconception can be traced back to the specific earlier concept a student hasn't mastered yet instead of being labeled in isolation, add multi-round adaptive follow-ups that keep generating targeted questions until mastery is actually confirmed rather than stopping after one check, and expand the micro-lesson library and subject coverage beyond what we currently support.

Built With

• claude
• express.js
• fastapi
• javascript
• manus
• node.js
• postgresql
• python
• react
• sentence-transformers
• supabase