Luminary

Our project Page

Inspiration

"The most expensive mistake a researcher can make is spending four years solving a problem - only to discover someone in the next building already solved it." This isn't a hypothetical. It's happening right now, on every campus, in every department, every single day. A PhD student spends years building a federated learning pipeline for healthcare data. Then discovers that a researcher from the Health Sciences department - literally the next building over - published the exact same work four months ago. Four years. Gone. Not because the research was bad. Because there was no system that shows you what other departments are working on right now. Google Scholar only shows published papers - nothing current. Emails to professors go unanswered for weeks. The invisible wall between departments costs researchers years of their lives. We built Luminary to tear that wall down.

What it does

Luminary lets researchers describe their work in plain English and instantly find other researchers at connected universities working on the same problems - not papers published years ago, but work happening right now. You type what you're working on. Luminary shows you who else is working on the same thing, how closely their work matches yours as a percentage, what datasets they have, whether those datasets are IRB approved, and whether they're open to collaboration. You can send a collaboration request directly from the platform. There's also a built-in multi-agent AI assistant that finds relevant datasets, academic papers, and tutorials for any research topic - three specialist agents running in parallel powered by Groq's LLaMA-3.3-70B. The whole thing is privacy-first. Raw research data never leaves any university. Only encrypted representations are shared. FERPA compliant. IRB compliant. By architecture, not by policy.

How we built it

We built Luminary as a three-layer system. The frontend is React with Vite, deployed on Vercel. Every screen — search, results, researcher profiles, the upload portal, and the AI assistant - is a single-page app with a custom dark theme we designed from scratch. The backend is FastAPI running on Render. When a search comes in, it goes through a full pipeline: Pinecone vector search retrieves the closest researchers by semantic embedding, federated learning models predict collaboration probability for each match, and a quantum-inspired QAOA optimizer produces the final ranked list with a collaboration score. For the federated learning layer, we trained three models - Random Forest using tree-merging federation, Gradient Boosting using prediction averaging, and Ridge Regression using FedAvg on coefficients - then combined them into an ensemble with optimized weights. For vector storage, every researcher's work is embedded into an 8-dimensional semantic vector and stored in Pinecone. Searches query Pinecone directly so results reflect every researcher in the network, not just a local snapshot. The AI assistant is a separate Flask service also on Render, using Groq's API and DuckDuckGo search. An orchestrator LLM decides which specialist agents to activate - DataBot for datasets, PaperBot for papers, ArticleBot for tutorials - and runs them in parallel.

Challenges we ran into

The hardest part was making everything work together, not building any single piece. Replacing our local JSON store with Pinecone mid-project broke the entire FL and QAOA pipeline because the RESEARCHERS variable was being imported at module load time before Pinecone had loaded anything. We spent hours debugging why searches returned 0 results even though the data was clearly in the index. Deploying three separate services - Vercel for the frontend, two Render services for FastAPI and Flask - with correct CORS headers, environment variables, and port bindings was far messier than expected. Every service needed to know about the others, and getting them all talking in production took most of our final day.

Accomplishments that we're proud of

We actually deployed it. A fully working full-stack ML application — React frontend, FastAPI backend, Flask multi-agent assistant, Pinecone vector database, federated learning models, QAOA scoring — all live and talking to each other on the internet. The search pipeline genuinely works. You type "ovarian cancer federated learning" and the researcher who uploaded that exact dataset appears at the top with a 100% collaboration score. That moment when it first worked felt really good. We're proud of the privacy architecture. Researchers can discover each other's work without any institution ever sharing raw data. That constraint forced us to think carefully about every design decision, and the result is something we think could actually be deployed in a real university setting.

What we learned

Federated learning in practice is nothing like the textbook version. The moment you have variable numbers of nodes, small datasets, and real heterogeneous data, every assumption breaks. We rewrote the FL pipeline three times. We learned that a great product idea means nothing without obsessing over the data layer. Getting Pinecone, the in-memory cache, and the FL training data all pointing to the same source of truth was the difference between a demo that works and one that doesn't. We also learned that deploying is a skill of its own. Writing the code is maybe 60% of the work. The other 40% is environment variables, CORS policies, port bindings, cold start times, and branch protection rules on GitHub at 2am.

What's next for Luminary

The immediate next step is real university partnerships. We want to start with Northeastern's Khoury College - connect 3 internal research systems, onboard 100 researchers, and measure whether it produces actual cross-department collaborations. On the technical side, we want to upgrade from our 8-dimensional keyword embeddings to proper 1536-dimensional LLaMA text embeddings for much richer semantic search. We also want to build a proper IRB-aware dataset access request workflow so researchers can formally request access to datasets they find on the platform. Longer term, the network effect is what makes this valuable. Every university that joins makes the platform smarter for everyone else. Our roadmap takes us from one department at Northeastern, to the full university, to a Boston-area multi-university network including MIT, Boston University, Drexel, and Tufts - each one a federated node in a system that gets better the bigger it gets.