Dashboard
Dashboard
User Input Form - Takes user inputs to generate the personalized learning path.
Generated Learning Path is displayed here, along with the respective CO / PO mappings.
Progress Tracking and Analysis
CO / PO Outcomes
Assessment and Test Module
Assessments Module
Profile and Settings

Inspiration

Outcome-Based Education (OBE) is the backbone of how Indian engineering colleges are accredited — every course maps to Course Outcomes and Program Outcomes under NBA guidelines. But none of that structure exists for how students actually learn outside the classroom — self-study, upskilling, closing a skill gap before placements. Students turn to Coursera, Khan Academy, or just ask ChatGPT, and get generic recommendations with zero connection to the outcomes their own curriculum is built around.

We also looked closely at CO-PO mapping tools already used by colleges — and realized they all solve a different problem: mapping faculty-defined, static course content to outcomes for accreditation paperwork. Nobody was mapping a personalized, AI-generated student learning path to those same outcomes. That specific, narrow gap became the project.

What it does

A student enters their goal, current skills, experience level, and available time. An LLM generates a structured, phase-by-phase learning roadmap — topics, resources, and milestones. Each learning objective is tagged to a predefined Course Outcome, which maps to Program Outcomes through a fixed CO→PO matrix maintained by the system — never invented by the LLM itself. As the student progresses and takes assessments, the system classifies performance (strong / moderate / weak) and adapts the remaining roadmap in real time — inserting remedial topics for weak scores, skipping ahead for strong ones — then reflects that back into updated outcome-attainment numbers.

How we built it

We started with groundwork before writing code: a structured literature survey across IEEE Xplore, Google Scholar, and ResearchGate, comparing our approach against reinforcement-learning-based adaptive systems and prompt-engineered tutors like GPTutor. That survey shaped a design rule we treated as non-negotiable: the LLM identifies learning objectives, but never invents or assigns COs, POs, or their mapping — that data is predefined and backend-controlled, keeping the system explainable rather than a black box.

We originally scoped the backend in Flask, then pivoted to React + Spring Boot + PostgreSQL once we locked in our team's actual strengths — the architecture mattered more than the language, and our guide was fine with the change. Adaptive replanning runs on simple, deterministic thresholds (≥80% strong, 50–79% moderate, <50% weak) rather than a trained ML model — deliberately, since it's explainable and realistic to build and defend within a semester.

Challenges we ran into Keeping CO/PO mapping reliable. Letting an LLM freely assign academic outcomes risked inconsistent, unexplainable results — unacceptable for anything meant to plug into real accreditation workflows. We solved this by constraining the LLM to classification over a fixed outcome list, rather than open generation. Scope control. The full vision — roadmap generation, assessments, adaptive replanning, outcome-attainment dashboards — is a lot for one semester. We had to explicitly write down what not to build (no admin panel, no custom ML model, no multi-role auth) to keep it shippable. Differentiating from existing work. A deep patent and literature search showed the space is more crowded than it first looks — CO-PO automation tools already exist commercially in India. We had to sharpen our pitch to the specific combination that doesn't exist yet: personalized, LLM-generated paths tied to outcomes, not static curriculum mapping. Prompt reliability. Getting an LLM to return consistent, structured JSON for a roadmap — across very different student goals and skill levels — took real iteration on prompt design. Accomplishments that we're proud of Landing on a genuinely defensible novelty claim after checking it against real prior art — not just asserting it, but verifying it against patents, papers, and commercial tools before committing to it. Designing a CO/PO mapping mechanism that's explainable by construction: if anyone asks "how do you know the AI didn't make that outcome up," the honest answer is "it can't — the mapping is predefined." Drafting a full provisional patent specification (claims, abstract, block diagrams) for the outcome-mapping methodology, with our guide as a co-applicant. Making a deliberate, defensible architecture pivot mid-project (Flask → Spring Boot) based on team strengths, without losing any of the system design already locked in. What we learned

The hardest part of an "AI project" is rarely the AI — it's deciding what the AI shouldn't be trusted to do. Constraining the LLM's role to exactly what it's reliable at, and keeping the academically sensitive parts (CO/PO mapping) deterministic, made the system both more defensible and more honest about what it actually does.

What's next for Adaptive OBE Learning Path Generator

Finishing the adaptive-replanning loop end-to-end, building out the CO/PO attainment visualizations, and pursuing the patent filing for the outcome-mapping methodology through our college's IPR cell.