ScholarPath — Explainable Scholarship Matching

• 

  ScholarPath — Explainable Scholarship Matching

Inspiration

A field study of marginalized students found that 98% of those surveyed were eligible for a scholarship — but 1 in 3 never received any financial assistance, mainly due to procedural delays, paperwork complexity, and lack of awareness. Government data tells the same story at scale: declining scholarship beneficiary numbers among SC/OBC/EBC/DNT students, despite available funds.

We looked at India's National Scholarship Portal, the natural benchmark, and found it already does basic eligibility checking — but stops there. It's government-schemes-only, gives a yes/no with no explanation of why, and doesn't track deadlines or missing paperwork. Eligible students are losing money not because they don't qualify, but because nobody tells them why they qualify, what's missing, or when it's due.

That gap — between being eligible and actually getting paid — is what we built ScholarPath to close.

What it does

ScholarPath matches students to scholarships across government, state, private, and institutional sources, and explains every verdict instead of giving a black-box yes/no.

• Profile builder — academic, financial, demographic, and geographic details, collected once and editable anytime.
• Explainable matching engine — every scholarship is scored across six dimensions (Academic, Financial, Demographic, Geographic, Documentation, Deadline), each with a verdict and the exact reason, quoting the scholarship's own published criteria — never an unexplained score.
• Real document verification — instead of a self-declared checkbox, students upload their actual certificates. A classify → extract → validate pipeline reads the document, pulls out the relevant fields (name, income, category, etc.), and checks them against the student's profile — catching real problems like a name mismatch or an income figure over the declared bracket, with the exact reason named.
• Live Scholarship Fit Map — a ranked view of every match, showing exactly what's missing for partial matches, so a scholarship visibly moves from "partial" to "eligible" the moment a student verifies the last missing document.
• Deadline tracking — every eligible or partial match surfaced and sorted by urgency, so nothing is lost to a missed date.

How we built it

• Backend: FastAPI + SQLite, with a rule-based matching engine and a document-verification pipeline adapted from a classify → extract → validate → decide architecture originally designed for mortgage-document underwriting, applied here to scholarship certificates instead.
• Frontend: a single responsive HTML/CSS/JS app — profile builder, document upload with a live pipeline visualization, the Fit Map, and a deadline tracker — with a Three.js signature visual on the landing page rendering the six real matching dimensions as an interactive 3D shape.
• Deployment: runs locally with nothing but a Python venv (no Docker), and is also packaged for one-click deployment to Vercel as a static frontend plus a Python serverless function.

Challenges we ran into

• Explainability without a black box. It was tempting to just return a yes/no. Making every single verdict trace back to a quoted piece of the scholarship's actual eligibility text — for six dimensions, across every scholarship — took real design work in the matching engine.
• Verifying documents without an expensive AI pipeline. We designed the classify/extract/validate contract to be swappable for a real OCR/LLM backend, but built the working version as a deterministic reference implementation so the whole product runs end-to-end with zero API-key dependency — while still catching real mismatches (wrong name, income over bracket, wrong category).
• Keeping it genuinely deployable. No Docker, runs on a laptop in two commands, and also deploys to Vercel — which meant designing around Vercel's read-only filesystem (SQLite has to live in /tmp there) from the start rather than bolting it on later.

Accomplishments that we're proud of

• A matching engine where every verdict is explainable — no unexplained scores, ever.
• A document verification pipeline that actually catches real problems (name mismatches, over-bracket income, wrong category) instead of just trusting a checkbox.
• Watching a scholarship move live from PARTIAL to ELIGIBLE the moment the last required document is uploaded and verified — the whole loop works end-to-end, not just in a mockup.
• A product that runs locally with no Docker and is also ready to deploy to Vercel, with no code changes between the two.

What we learned

• Government scholarship data shows the core issue isn't discovery — it's fragmentation and process, since eligible students are still losing out.
• Explainability isn't a nice-to-have UI feature — it has to be designed into the data model from the start (every verdict needs an evidence field), or it gets bolted on badly later.
• Serverless platforms like Vercel are a great fit for static + API demos, but ephemeral storage is a real constraint worth designing around early, not discovering at deploy time.

What's next for ScholarPath

• Upgrade matching to LLM-backed extraction — same explainable contract, real scholarship text parsed instead of hand-coded rules.
• A real scholarship database — move past our 5 seed entries to a scraped and verified national dataset.
• Real authentication — per-student accounts, replacing the current single shared demo profile.
• An institution/counselor dashboard — aggregate eligibility gaps across a cohort ("40 students are one document away from qualifying").
• A persistent database — Vercel Postgres or Neon, for real multi-user use beyond the demo.

Built With

• css3
• fastapi
• html5
• javascript
• pydantic
• python
• rest-api
• sqlalchemy
• sqlite
• three.js
• uvicorn
• webgl