Back to Meetpuri's profile
20views

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

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

Overview

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.