ATHARVA BARAD
Projects / Product & information systems
MIS capstone · Five-person team · Mar–Jun 2026

UniPath: Designing an AI-Assisted Student Lifecycle Platform.

A product and systems capstone that translated a broad student-support idea into user roles, a six-layer architecture, a normalized data model, prototype ranking/matching logic, and explicit limits on what the AI could claim.

Prototype boundary: the project used synthetic/prepared data and design-level integrations. It did not include a production backend, live university feeds, a deployed production database, or validated real-world admissions prediction.

My core ownership: the relational model

I personally designed the normalized 34-table PostgreSQL schema/ERD with UUID primary keys, explicit foreign keys, and junction relationships.

Ranking without pretending preferences are universal

The design used weighted composite scoring across ROI, academic quality, satisfaction, industry outcomes, location, and extracurricular opportunities, normalized via min-max scaling.

Semantic matching plus hard constraints

The match engine combined OpenAI embeddings, cosine similarity, semantic matching, and hard filters to align student goals with university/course descriptions.

Admissions likelihood as a prototype signal—not a verdict

The POC used logistic regression to produce probability, confidence, profile-gap, and risk-indicator outputs. These were prototype outputs, not validated admissions predictions.

Interactive · Python POC logic

See when UniPath would use AI matching—or fall back

The POC deliberately gated semantic matching. Hard filters run first; AI matching only activates after minimum profile completeness and goal-text thresholds and only when the user opts in and the AI service is available.

1
Hard filtersBudget · qualification level · location preference · language of instruction.
2
Semantic matchGoal statement + candidate descriptions → embeddings → cosine similarity.
3
Admission likelihood + explanationPrototype calibrated logistic output + profile gap analysis; still disclosed as an estimate.
active result mode
40%minimum profile completeness
20 wordsminimum goal length
~90%candidates removed by hard filters in the design

This reproduces the decision logic documented in the capstone/POC. It does not call an external AI model or produce a real admissions prediction on the portfolio site.

What I built versus what the team built

Individual ownership: the normalized 34-table PostgreSQL schema/ERD and Python proof of concept. Shared team work: the broader six-layer architecture, API/data-flow concepts, user journeys, business model, and governance considerations.

That distinction matters because systems projects blur ownership easily. I want the architecture to show the team’s integrated design while still making clear which technical artifacts I personally produced.

How the pieces fit into a complete student lifecycle

I co-developed the six-layer architecture, API/data-flow concepts, role-based user journeys, and explainability/fallback/bias/privacy considerations with the team.

UniPath — six-layer modular architecture Shared team architecture; my individual ownership centered on the 34-table schema/ERD and Python POC. 1 · UsersProspective · Enrolled · Alumni · University Admin · Platform Admin · Employers 2 · FrontendStudent portal · University admin portal · Platform dashboard · Employer portal 3 · Backend APIsAuth/roles · Profiles · Universities/courses · Ranking · AI match · Admission likelihoodCourse recommendation · Academic progress · Alumni · Notifications · Payments · Audit/compliance 4 · DataPostgreSQL + pgvectorSearch · object storage · analytics/BI34 normalized relational tables 5 · AI & AnalyticsRanking · semantic matching · admission likelihoodCourse intelligence · academic analytics · alumni ROI feedback 6 · External integrationsOpenAI · university feeds · employer/job feeds · email/SMS · Stripe · analytics tooling Phased rollout: Phase I discovery/apply → Phase II enrolled student support → Phase III alumni/career feedback loop
Six-layer product architecture. Users, front-end experiences, APIs, data, AI/analytics, and external integrations were designed as separate but connected layers, with a phased lifecycle from discovery through alumni/career feedback.Adapted from the final team capstone architecture; 34-table schema and Python POC were my individual artifacts.

Business model and implementation realism

The team modeled $356,300 in Year 1 revenue against $240,000 in operating cost, producing a $116,300 academic operating surplus. More important than the number itself was connecting product architecture to a plausible SaaS model: who pays, which features create value for each side, what data infrastructure costs money, and which integrations would need to be phased rather than promised all at once.

Responsible-AI constraints were part of the design

The team explicitly considered explainability, fallback behavior, bias, privacy, and role-based access. In the prototype, AI-assisted ranking or matching was meant to support student decisions, not silently convert uncertain signals into authoritative admissions or career outcomes.

AI confidence vs. user trust article