Meetpuri Goswami

Meetpuri Goswami

L.D. College Of EngineeringAhmedabad, Gujarat
JavaScriptHTML/CSSTypeScriptReact
MemoryVerse AI '26 (ORION — An AI-Powered Digital Identity Platform )

MemoryVerse AI '26 (ORION — An AI-Powered Digital Identity Platform )

MemoryVerse AI '26 (ORION) Your AI-powered digital identity. Orion turns the scattered evidence of what you've built and learned — resumes, certificates, project reports, internship letters, GitHub repos — into a single, living profile. Drop your documents in, and Orion reads them, figures out what they are, and stitches them into a searchable, visual picture of your skills and growth over time. How Orion maps to the evaluation criteria : Quality of AI organization, categorization, and information retrieval (40%) Every uploaded document — PDF, DOCX, or URL (including GitHub repo READMEs, fetched directly via the GitHub API) — is passed to Gemini with a strict extraction prompt that returns structured JSON: category, title, issuing organization, date, a 2–3 sentence summary, and the specific technical skills mentioned. Documents are stored with this structured metadata in Postgres, so retrieval later is fast, filterable, and grounded in what the document actually says (see documents.functions.ts). Use of AI/ML techniques — embeddings, NLP, semantic search, knowledge mapping (25%) Embeddings: every document is embedded with gemini-embedding-2 (1536-dim) and stored in a pgvector column. Semantic search / RAG: search queries are first run through an NLP intent-extraction step (to detect an implied category filter and clean the query), then embedded and matched against stored document vectors via a Postgres match_documents similarity function, and finally the top matches are fed back into Gemini as context to produce a grounded, cited answer — a full retrieve-then-generate (RAG) pipeline (see search.functions.ts). Knowledge mapping: a separate job computes pairwise cosine similarity between document embeddings plus shared-skill overlap, then asks Gemini to label the relationship type and rationale between related documents, producing the data behind the relationship graph (see graph.functions.ts). Innovation, usefulness, and user experience (20%) Beyond search, Orion generates an AI-written, year-by-year narrative of the user's growth (Timeline view), a visual force-directed graph of how skills/projects/certifications connect (Graph view), and an aggregated Identity view summarizing top skills and history — turning a pile of static files into something closer to a personal knowledge base than a document locker. Clarity of explanation, architecture, and thought process (15%) What it does : Understands your documents. Upload a PDF, DOCX, or a link (including a GitHub repo URL — Orion will pull the README), and it's automatically classified into categories like Project, Certification, Internship, Achievement, Academic, Resume, or Repository, with a short summary and the specific technical skills it mentions. Answers questions about your own history. Ask "What Python projects have I done?" or "List my AI/ML certifications" and Orion runs a semantic search over your documents and gives you a direct, cited answer. Maps how your work connects. A force-directed graph links documents that share skills or themes, so you can see the relationships between a certification, the project it fed into, and the internship that followed. Builds your timeline. Documents are grouped by year with a one-line, AI-generated summary of what that year represented in your growth. Summarizes your identity. A dashboard view aggregates your most common skills, project history, and credentials into one profile page. See the Architecture and Thought Process sections : https://github.com/MeetpuriGoswami-dev/Orion/blob/main/README.md Innovation, usefulness, and user experience (20%) Orion reuses the same embeddings and metadata generated at ingestion across three different views, instead of bolting a chatbot onto a file drawer. Timeline groups documents by year and has Gemini write one sentence per year describing what actually happened, so it reads like a story rather than a list. Graph is the part I like most: a force-directed canvas where documents connect by embedding similarity and shared skills, and an LLM labels what the relationship actually is (enables, evidences, builds_on, applied_in) instead of just drawing a line and calling it "related." Generic soft skills like teamwork and communication are filtered out too, since they cluster everything into a hairball and add nothing. Identity rolls it all into something closer to a living resume: skill frequency counts, chronological projects, certifications, an auto-generated "role" tag. Search is what actually delivers on the brief's success metric. Ask a question and you get a direct answer plus retrieved source cards with similarity scores, each with a "View original" button that opens the real PDF or DOCX via a signed URL. The AI answer doesn't replace the file, it points back to it — that's the "never search through folders again" moment, backed by a real file opening rather than just a confident-sounding answer. Stack Frontend: React 19, TanStack Start / TanStack Router (file-based routing), Tailwind CSS v4, shadcn/ui + Radix primitives Data & auth: Supabase (Postgres, pgvector for embeddings, storage, auth) AI: Google Gemini — gemini-2.5-flash for extraction, classification, and Q&A; gemini-embedding-2 for semantic search embeddings Visualization: react-force-graph-2d (relationship graph), Recharts File parsing: mammoth (DOCX), pdf-parse (PDF) Uploads: react-dropzone Thought process : Why structured extraction instead of raw storage: classifying and summarizing at ingestion time (rather than at query time) means search, graphing, and the timeline can all reuse the same clean metadata instead of re-parsing documents on every request. Why RAG instead of keyword search: portfolio documents use inconsistent language (a certificate might say "deep learning," a project might say "neural networks"), so embedding-based similarity finds relevant documents that keyword matching would miss, and grounding the final answer in the retrieved documents keeps responses accurate instead of hallucinated. Why a graph, not just a list: skills and experience are relational — a certification often leads to a project, which leads to an internship. Surfacing that as a graph (similarity + shared skills + an LLM-labeled relationship type) tells a richer story than a flat document list. Why Gemini for both generation and embeddings: keeping both on one provider (via ai-gateway.server.ts) simplifies the API surface and keeps the whole AI pipeline swappable behind a single module if the model needs to change later. Trade-offs: classification and relationship-building depend on LLM output quality, so extraction prompts are deliberately strict (fixed JSON shape, explicit "don't invent facts" instruction) and failures fall back to safe defaults rather than breaking the UI.

5 media files · orion-ai-swart.vercel.appView
Queue Cure '26 (ClinicQ — Real-Time Digital Queue Management for Clinics)

Queue Cure '26 (ClinicQ — Real-Time Digital Queue Management for Clinics)

Indian neighbourhood clinics see 30–150 walk-in patients daily with zero digital infrastructure. Patients take a paper token, sit in a crowded waiting room, and have no idea when they'll be called — could be 10 minutes or 2 hours. Receptionists manage everything via handwritten registers and shouting token numbers. The gap: existing solutions (hospital HMIS, WhatsApp groups, physical token machines) are either too expensive, manual, or hardware-dependent. No tool exists that's free to deploy, opens in any browser, and gives patients live visibility without creating an account. Benchmarked 4 existing solutions (HMIS, WhatsApp, token machines, SaaS) and documented why each fails a 1-doctor walk-in clinic before writing code. Key decisions: TanStack Start over Next.js for edge-native type safety; Supabase CDC over polling after measuring a 3–5s lag that made "live" feel dishonest. Scrapped patient auth entirely — a UUID in localStorage removes the biggest drop-off for elderly, low-tech users. Rewrote ETA mid-build: the admin slider was inaccurate. Replaced it with real average computed from the last 50 seen_at timestamps, filtering gaps above 45 minutes to exclude lunch breaks. Shipped a full product in one sprint — patient flow, receptionist dashboard, billing, reports, and settings. The Patient Waiting Room gets updated in real time with no refresh needed again and again, it auto updates. The Avg. Consultation and Wait Time are not hardcoded, they are calculated from last 50 entries. Key metrics: <500ms queue sync, <50ms cold start on Cloudflare edge, 0 REST endpoints, client-side PDF with no server cost, patient registration under 20 seconds with no account required. Open/close toggle broadcasts to all patient screens instantly via CDC. Dynamic Wait Times: Calculated wait times using real consultation intervals, filtering out long gaps like lunch breaks. TanStack Loaders: Used server-side loaders to prefetch queue status for instant page loads. Atomic State Updates: Structured database updates to atomically move patients from active consultation to done and promote the next waiting patient. Cookie Auth: Fixed cookie-based authentication middleware to prevent session drops during routing.

12 media files · clinic-q-tau.vercel.appView
CricMind: High-Performance IPL Analytics & AI Simulator

CricMind: High-Performance IPL Analytics & AI Simulator

IPL cricket data is scattered across dozens of sites — fragmented, ad-heavy, and requiring constant internet. Fans have no single, privacy-respecting tool to explore 19 seasons of ball-by-ball data interactively. No platform lets you ask natural questions like "Does winning the toss matter?" and get instant data-backed answers. We built CricMind — a fully offline, browser-based IPL analytics platform that processes 1,226 match files into interactive dashboards, a conversational AI assistant (CricAI), and a match simulator — zero APIs, zero tracking, zero server dependency. Process We sourced 1,226 Cricsheet ball-by-ball JSON files (IPL 2008–2026) and built a Node.js preprocessing pipeline that normalizes team names, computes player stats for 680+ cricketers, and generates phase analysis (Powerplay/Middle/Death), toss impact data, and H2H records — outputting one optimized JSON for the frontend. We chose React 19 + TypeScript + Vite for an offline-first SPA. Charts use Recharts, animations use Framer Motion. CricAI is a local NLP engine with 11 query handlers — not a cloud LLM — keeping everything in-browser. We iterated on design using glassmorphism, neon accents, and seamless video backgrounds. Results Processed 395,011 deliveries across 1,226 matches and 680+ players — all running offline in-browser with zero API calls. Key discoveries: toss winners only win ~50.6% of matches (myth busted), but chasing teams win 53.8% vs 44.3% batting first — a 9.5% delta. Death overs produce the highest run rate (9.54) despite being only 25% of an innings. Built a working CricAI chatbot handling H2H queries, player lookups, toss analysis, and season data — plus a Monte Carlo match simulator with confidence scores. Reflection I'd replace CricAI's rule-based NLP with a local edge LLM (like Gemma) for open-ended queries while staying offline. I'd add ball-by-ball match replay timelines using our 395K delivery dataset. The simulator needs a real Monte Carlo engine (10K+ scenarios) instead of weighted probability. I'd invest the first hour building a complete design token system before any pages — would've saved 40% time later. Finally, I'd ship as a PWA with service worker caching for permanent offline mobile access and add PNG/PDF export for sharing.

11 media files · cricmind.vercel.appView

This is Meetpuri’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours